7:39 a.m.
On 05/28/2015 04:26 PM, Sanne Grinovero wrote:
On 28 May 2015 at 16:38, Jason Greene <jason.greene(a)redhat.com>
wrote:
>
>> On May 28, 2015, at 9:56 AM, Scott Marlow <smarlow(a)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/hibe...
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#JPARefer...