[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9

[Scott Marlow]

On 05/28/2015 04:26 PM, Sanne Grinovero wrote:
> On 28 May 2015 at 16:38, Jason Greene <jason.greene at redhat.com> wrote:
>>
>>> On May 28, 2015, at 9:56 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>
>>> On 05/28/2015 06:30 AM, Sanne Grinovero wrote:
>>>> Could someone explain please, why it's hard to have a deployer just
>>>> use a different JPA implementor which the user might want to provide?
>>>
>>> If you mean Hibernate 5.x specifically, we started the integration on
>>> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
>
> Thanks that's very nice, but I'm really just asking why such adapters
> are needed, and understand their purpose.

I'll answer why we have adapters but first lets talk about modules and 
persistence providers.

The JPA subsystem/container/deployer in WildFly, deals with mapping user 
application persistence units (e.g. parses persistence.xml) to an 
available persistence provider in the system.  In mapping the 
persistence unit to an available persistence provider, we strive to make 
it easy for applications to deploy.  Most applications do not have to 
fill in the "integration" level properties, that the persistence 
providers need to satisfy the 
javax.persistence.spi.PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo 
info, Map map) call.  Instead, we introduced integration adapters that 
set "integration level" properties on behalf of applications (e.g. see 
[1]).  The "integration level" properties are set prior to the call to 
createContainerEntityManagerFactory().

There isn't a way to specify that a persistence provider adapter should 
not be used but that would be a small enhancement that we could talk 
about adding, if that is ever needed.

>
> For example since I have primarily "preview testing" needs I wonder if
> we could do something similar within our testing utilities, so to
> avoid bothering you in future for each and every update we might want
> to test.

I'll think about this and follow up with you on irc in the next few days.

>
> Another example could be to see if it makes sense to include the
> adapters within the Hibernate feature packs for WildFly - if the
> integration API is stable enough for the adapter to work with various
> servers that could lead us to work more together on jipijapa long
> before it's integrated in WF.
> For us it's not practical to lock Hibernate testing to WildFly
> releases, and doesn't help us to test new versions of Hibernate to run
> fine on versions of the application server which have already sailed.

As of yet, there has been almost zero community need for the separate 
Jipijapa project.  To do what your looking for, we still may not need a 
separate Jipijapa project.  External projects that align with the 
Jipijapa spi, can do so with the Jipijapa source in WildFly.

There are two options for the external Hibernate testing.

1). Setup a static module that contains the persistence provider + 
adapter classes (these can be separate modules that depend on each other).

2). Deploy the persistence provider and adapter classes with each test 
deployment.

>
>>>
>>>>
>>>> I'm pretty sure I know how to start a JPA context in plain JavaSE, and
>>>> don't need to know which implementor version I'm going to use, other
>>>> than for sake of configuration.
>>>>
>>>> The WildFly documentation mentions this property
>>>> "jboss.as.jpa.providerModule", which sounds great on paper and it
>>>> would be a nice usability improvement if it would also actually work
>>>> as it suggests.
>>>
>>> You are complaining a lot lately.  We purposely designed for known use
>>> cases.  There are other ways to get the dynamic environment that you are
>>> looking for then complaining that the WildFly JPA subsystem
>>> "jboss.as.jpa.providerModule" option doesn't work.
>>
>> I have probably missed other threads, but I didn’t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn’t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear.
>
> Correct, and apologies for the wording Scott!

No problem, my mistake on thinking that you were complaining.  We have 
worked together on a lot and I think its great that you are opening a 
dialog about the JPA container/subsystem/deployer in WildFly.  I'm all 
for improving the documentation as well.  In the WildFly 10 
documentation, we could definitely say a lot more [2].

>
> I do realise I'm stretching the limits far beyond their intended
> usage, it's not shocking me to hit some surprises. I'm actually
> excited about the possibilities and didn't mean to "complain" but to
> point out an issue in hope to improve as I'd hope to use it.

One limitation is that only the default persistence provider is wired 
for clustering.  I looked at improving this last year but didn't have 
enough time.  I think it will actually be easier to improve clustering 
of various persistence providers (if there is desire for that), after we 
merge Jipijapa back into WildFly (pr already created).

> The documentation seems to claim this is as easy as to point to the
> module containing the JPA implementation of choice; that would be
> extremely handy to solve several testing issues we have - not only
> with Hibernate Search but across the board.
> Adding a clarification on which modules are accepted would be nice;
> although maybe then this option should rather be a closed enumeration
> of short hand names, rather than give the user the option to freely
> name any module?

Also see the "Determine the persistence provider module" below [2].  I 
have never had any issues specifying a custom module myself.  There 
really isn't a fixed limit on the modules.  If an adapter is not found 
for the module, a noop integration adapter is used.

> But please let's not change the meaning of this property if there is
> hope we could eventually get it to work with any custom JPA module.
>
> Thanks,
> Sanne
>
>> As always I think its great for us to discuss if and how our integrations could be better.
>>
>>>
>>>>
>>>> There's plenty of evidence on StackOverflow that the current
>>>> limitations are unexpected. For example, Spring moved to Hibernate 5
>>>> and people won't be able to use your stable line of the application
>>>> server with Spring; I'd hope we could implement a plan to prevent this
>>>> from happening at the next upgrade cycles.
>>>
>>> The question is whether the Hibernate 5.0 release schedule can align
>>> with the WildFly 10 schedule, so that we can do the work.
>>
>> Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn’t that far away.
>>
>>>
>>>>
>>>> Thanks,
>>>> Sanne
>>>>

Scott

[1] 
https://github.com/scottmarlow/wildfly/blob/jipijapa3_hibernate5/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernatePersistenceProviderAdaptor.java#L86 
is setting the AvailableSettings.USE_NEW_ID_GENERATOR_MAPPING property 
if the application didn't.

[2] 
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties