I don't think that Hibernate took it lightly when the new (improved) id generators were added, which is why the old id generators were kept around. 

Were you lucky enough to get "unique key already exists" type errors when the wrong sequence number generator was used?  I believe that this issue was documented in our EAP 6.x release notes.  It is also mentioned in a few different community documents (for those lucky enough to find/read them).  Look at How do I migrate my application from AS5 or AS6 to AS7 and migrating from AS5 to WildFly.  You might also read migrating from AS7 to WildFly (doesn't mention the new_generator_mappings setting but has other tips). 

Also, look at https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties, which describes the new_generator_mappings setting.

By the way, starting with Hibernate 5 (which is in WildFly 10.0.0.Final), hibernate.id.new_generator_mappings defaults to true.  I like the idea of being able to specify default persistence unit properties to be used, although I think that is a separate concern than the one raised by your post.  Currently, you have to update all of your applications persistence.xml. 

Look in the Hibernate doc for an example of specifying "<generator class="org.hibernate.id.TableHiLoGenerator">", I think you will want to look at using org.hibernate.id.enhanced.SequenceStyleGenerator for the generator class.

Scott

I'm sad to hear that the only way to currently choose between the generators is to roll 2 versions of all our existing PU jars (we already have too many configuration variants for my liking, controlling the parameters using system properties to bring down the amount of PU jar variants was one idea ).

My preference would be for a patch to WildFly, that allows any persistence property to be specified globally, via standalone.xml configuration settings.  If we don't do that, next best thing could be a system property override.  I think the precedence ordering would be something like the following:

1. persistence.xml settings take precedence over global settings. 
2. global settings take precedence over the WildFly JPA container/deployer code that.
3. The WildFly JPA container/deployer sets certain PU integration properties if those properties are not already set in the persistence.xml PU or global settings.

The system property check idea is a good alternative which would also be specified in the standalone.xml:

I'm surprised that Wildfly is so adamant about enabling the new generators - I would expect it to respect my settings and only enable the new generators as a reasonable default is missing. (other hibernate settings seems to support being defined as standalone.xml system properties and I see that starting wildfly with a -D<generator setting> ends up with the property being passed to hibernate twice with both a true and false value - the current mechanism seems inconsistent).

Are you saying that Hibernate is reading the hibernate.id.new_generator_mappings system property setting?

Is there a realistic chance that wildfly will allow us better control of the generator mappings setting in near future? (say 3 months)

I think that this is sounding like a reasonably small code change (a few lines for checking for security manager permissions to read system properties and a few lines changed to use the system property value).  Do you want to create a WFLY jira for this? In terms of scheduling, I cannot promise when the patch will be merged in.  We are working on WildFly 10.1.0 currently.  If you were able to submit a patch soon, it would probably make it in (I have no idea when WildFly 10.1.0 will be complete).  If its really important to have a fix soon, consider buying EAP.  If you won't be submitting a patch for the WFLY issue, just don't assign it to yourself.  Please update this thread with the WFLY issue link after you create it.

I really appreciate hearing about this problem.  Thank you for taking the time to report it!

Scott

Looks like Hibernate would also read the system property setting as well.  Thanks for pointing out that conflict also, that would be addressed by a code change in WildFly. 

Thanks again Chris, I'll probably address this issue in a future release of WildFly.  I don't think it will be very difficult.  If you or anyone else is interesting in contributing to WildFly, I think this would be a good issue to start with.  I'd be happy to provide guidance on making the change.

Scott

Hi Scott,

I am trying to upgrade an EJB project that we have from JBoss 4.2.3 to Wildfly 9.0.1

All our entities are inheriting from a supper class named RootEntity which has the Id property as you can see below:

@Id

  @Column(name = COLUMN_ID)

  @GeneratedValue(strategy = GenerationType.TABLE, generator = GENERATOR)

  @TableGenerator(name = GENERATOR, table = GENERATED_IDS_TABLE_NAME, schema = "Common")

  protected long id;

This setting works fine on 4.2.3 (Hibernate creates a row for each entity type in the Id generation table), but when I upgraded to 9.0.1 I got "cannot read or init hi value".

I have spent few days trying to work around this issue - I tried to create a persistence.xml file with the following property

<property name="hibernate.id.new_generator_mappings" value="false"></property>

as mentioned in this thread, but this didn't help - I got an "unknown error" and I wasn't able to get this working. I even tried to specify the names of the key and value columns in the @TableGenerator attribute but It still didn't solve the issue

I am trying to come up with an elegant solution that will allow me to do the migration without significant code/db schema changes (While maintaining backward compatibility) and I would appreciate any advice you can give me on this.

Thanks,

Yoni

From a discussion in the Hibernate ORM Dev Hipchat room, I heard that Hibernate ORM is looking into having system properties take precedence over the persistence.xml settings.