[wildfly-dev] How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
Scott Marlow
smarlow at redhat.com
Fri Jan 31 11:46:30 EST 2014
On 01/31/2014 11:01 AM, Jason Greene wrote:
>
> On Jan 31, 2014, at 9:05 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> JPA Entity class enhancing/rewriting needs to occur in an early
>> deployment phase (before the application classloader is used to load the
>> enhanced classes).
>
> Yes, but this does not require access to a data source. Instrumentation simply needs to modify a small subset of classes (those marked as entities)
>
>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be
>> needed as a workaround.
>
> That’s not possible because @Resource can’t be processed without the final class loader.
>
>> There are other "if only we did things
>> differently" involved as well. For example, when using the Hibernate
>> Bootstrap spi to start the persistence unit, if we moved references to
>> the datasource to only be in the second deployment phase, that would
>> also help (when using Hibernate).
>
> That seems to be the real solution, and there is really no reason why a JPA provider needs to do anything with a datasource in order to know how to instrument the entity class.
This will definitely help, I think its also a big change in Hibernate
that hasn't happened yet. From a spec point of view, we had some
discussion about wanting to bring the two phase bootstrap into JPA and I
think we would push for only referencing the datasource during the
second phase (which we run during our INSTALL deployment phase).
>
>>
>> This is not the only case like this. There is also implicit CDI support
>> which uses the application classloader too early (leaving the
>> application deployer to choose whether to use CDI in entity listeners or
>> JPA class enhancing/rewriting).
>
> I’m not sure I follow the problems with this one.
This is one that we can also address in Hibernate (by moving the entity
listener registration to occur later) but just haven't yet. This
doesn't help us when we are using third party persistence providers.
I'm hoping to see this addressed in the future (got some positive
feedback on the JPA EG but will see what happens when the next JPA spec
revision is discussed).
>
>>
>> @DataSourceDefinition are also not available until Phase.INSTALL, so
>> they cannot be used with applications that expect entities to be
>> enhanced/rewritten.
>
> That shouldn’t matter if the data source usage was in a later phase.
Yes, I agree and will push for the 3rd party persistence providers to
also do that (in future JPA spec discussions).
>
>
>>
>> IMO, we should address these problems in the standards (EE specs).
>
> I’m not sure what specific spec flaw you are referring to here, this seems to really just be an implementation problem on our side. Unless you mean the JPA SPI with the temp class loading stuff, in which case I totally agree, but we don’t have to use it with our hibernate integration anyway.
We might be able to work around the issues in our Hibernate
implementation (by moving datasource/entitylistener registration to a
later phase) but we still need to work with 3rd party persistence
providers that do not have a two phase persistence unit bootstrap (since
we haven't agreed on how that will be done or if it will be part of the
standard).
>
>
>> If
>> we can improve our deployment implementation to better deal with these
>> "initialize me first if you want correct behaviour" situations, all the
>> better.
>>
>> On 01/31/2014 09:03 AM, Eduardo Martins wrote:
>>> IMHO this hint should not be needed, a PU referencing a java:comp or java:module datasource is already a hint that the PU will need a resource bound by another component bundled in same jar/war.
>>>
>>> By the way I’m not really a fan of using java:comp in a PU, it sets an dependency on a EE component, and that doesn’t seem right. Wouldn't be preferable to use the original java:jboss/datasources/ExampleDS JNDI name, or use an ear and define a java:app bind at application.xml, to be shared by all modules and components?
>>>
>>> —E
>>>
>>>
>>> On 31 Jan 2014, at 13:13, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> Great, thanks for reporting the issue Martin! Great to bring more
>>>> awareness of the deployment problem and workaround.
>>>>
>>>> Scott
>>>> On 01/31/2014 08:04 AM, Martin Andersson wrote:
>>>>> Thanks a lot!
>>>>>
>>>>> I can confirm that the app works now.
>>>>>
>>>>> Br,
>>>>> Martin Andersson
>>>>> Java EE developer at www.purplescout.se <http://www.purplescout.se>
>>>>>
>>>>>
>>>>> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow at redhat.com
>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>
>>>>> Hi Arjan,
>>>>>
>>>>> Great catch! Your change and adding an persistence unit hint that the
>>>>> persistence unit doesn't need to be started early:
>>>>>
>>>>> <property name="wildfly.jpa.twophasebootstrap" value="false"/>
>>>>>
>>>>> Helps the deployment succeed.
>>>>>
>>>>> It looks like ResourceReferenceProcessor is running during the
>>>>> Phase.POST_MODULE deployment phase, so we need to add a hint to the
>>>>> persistence.xml, that helps the persistence unit deploy later.
>>>>>
>>>>> [6]
>>>>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/subsystem/EeSubsystemAdd.java#L194
>>>>>
>>>>> Scott
>>>>>
>>>>> On 01/31/2014 06:25 AM, arjan tijms wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I looks like there's one bug in the example.
>>>>>>
>>>>>> jboss-web.xml defines jdbc/MyDS
>>>>>>
>>>>>> But persistence.xml references java:comp/env/MyDS
>>>>>>
>>>>>> Shouldn't the last one be at least java:comp/env/jdbc/MyDS?
>>>>> Regardless,
>>>>>> even with matching names it indeed doesn't work.
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 30, 2014 at 9:52 PM, Scott Marlow <smarlow at redhat.com
>>>>> <mailto:smarlow at redhat.com>
>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>>>
>>>>>> WFLY-2841 reports a deployment failure that occurs when a
>>>>> deployments
>>>>>> [1] persistence.xml, tries to use a resource reference [2]
>>>>> for the
>>>>>> datasource [3]. The error [4] mentions an unresolved
>>>>> (DataSource)
>>>>>> service dependency that is added to the persistence unit
>>>>> service [5],
>>>>>> instead of resolving the resource reference (and using the
>>>>> underlying
>>>>>> DataSource).
>>>>>>
>>>>>> How should we handle resource references for this case? Is
>>>>> there a way
>>>>>> to resolve the resource reference directly from deployers?
>>>>> Or do we
>>>>>> represent the resource reference as a service?
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> [1] test app is at https://github.com/umartin/wfds/
>>>>>>
>>>>>> [2] jboss-web.xml
>>>>>> <jboss-web>
>>>>>> <context-root>/wfds</context-root>
>>>>>> <resource-ref>
>>>>>> <res-ref-name>jdbc/MyDS</res-ref-name>
>>>>>> <res-type>javax.sql.DataSource</res-type>
>>>>>>
>>>>>> <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
>>>>>> </resource-ref>
>>>>>> </jboss-web>
>>>>>>
>>>>>> [3] persistence.xml pu def
>>>>>> <persistence-unit name="wfdsPU" transaction-type="JTA">
>>>>>> <jta-data-source>java:comp/env/MyDS</jta-data-source>
>>>>>> </persistence-unit>
>>>>>>
>>>>>> [4] {"JBAS014771: Services with missing/unavailable
>>>>> dependencies" =>
>>>>>>
>>>>> ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__
>>>>>> is missing
>>>>>>
>>>>> [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
>>>>>>
>>>>>>
>>>>>> [5]
>>>>>>
>>>>> https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/processor/PersistenceUnitServiceHandler.java#L358
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> <mailto:wildfly-dev at lists.jboss.org
>>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hälsningar,
>>>>> Martin Andersson
>>>>> Purple Scout AB
>>>>> +46 732 05 14 01
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
More information about the wildfly-dev
mailing list