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(a)redhat.com&gt; 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... > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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... 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(a)redhat.com > <mailto:smarlow@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... > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com > <mailto:smarlow@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... > > 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(a)redhat.com > <mailto:smarlow@redhat.com> >> <mailto:smarlow@redhat.com <mailto:smarlow@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... >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work. The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option. Br, Martin Andersson Java EE developer at www.purplescout.se <http://www.purplescout.se> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins(a)redhat.com <mailto:emartins@redhat.com>> 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(a)redhat.com <mailto:smarlow@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> <http://www.purplescout.se> >> >> >> On Fri, Jan 31, 2014 at 1:55 PM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >> <mailto:smarlow@redhat.com <mailto:smarlow@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... >> >> 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(a)redhat.com <mailto:smarlow@redhat.com> >> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> -- >> Hälsningar, >> Martin Andersson >> Purple Scout AB >> +46 732 05 14 01 <tel:%2B46%20732%2005%2014%2001> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Hälsningar, Martin Andersson Purple Scout AB +46 732 05 14 01

On 31 Jan 2014, at 14:33, Martin Andersson <martin.andersson(a)purplescout.se&gt; wrote: > I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work. > > The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option. > Well, aren’t you using it already in jboss-web xml? —E _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Yes. But I can add deployment descriptors for other application servers and have the same binary run in both production and dev setups. Br, Martin Andersson Java EE developer at www.purplescout.se On Fri, Jan 31, 2014 at 4:31 PM, Eduardo Martins <emartins(a)redhat.com&gt; wrote: On 31 Jan 2014, at 14:33, Martin Andersson <martin.andersson(a)purplescout.se&gt; wrote: > I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. Also, there is no hint anywere that there is a property you can set to make it work. > > The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option. > Well, aren’t you using it already in jboss-web xml? —E -- Hälsningar, Martin Andersson Purple Scout AB +46 732 05 14 01

On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson(a)purplescout.se&gt; wrote: > I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. It’s not, it’s actually implied by the standard, as you can define them in web.xml as well. It’s a lifecycle problem we need to solve. > Also, there is no hint anywere that there is a property you can set to make it work. > > The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option. Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution. A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so: <bindings> <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/> </bindings>

Thanks for your input! The alias and global naming does actually work! Br, Martin Andersson Java EE developer at www.purplescout.se On Fri, Jan 31, 2014 at 5:56 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: On Jan 31, 2014, at 10:39 AM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > On Jan 31, 2014, at 8:33 AM, Martin Andersson <martin.andersson(a)purplescout.se&gt; wrote: > >> I agree. I don't think mapping a datasource in jboss-web.xml is such an exotic use case. I should just work. > > It’s not, it’s actually implied by the standard, as you can define them in web.xml as well. It’s a lifecycle problem we need to solve. > >> Also, there is no hint anywere that there is a property you can set to make it work. >> >> The proprietary jboss namespace is not an option since I want to be vendor neutral, but ear/java:app is definitely an option. > > Another solution specific to EE7 is you can leave the jta-data-source undefined in persistence.xml which will use the platforms default data source. We allow you to point that anywhere. However, that limits you to one, so not really a complete solution. > > A more complete solution is to use a common global name, and define an alias to your deployment in our naming subsystem like so: > > <bindings> > <lookup name="java:global/env/FooDS" lookup="java:jboss/datasources/ExampleDS"/> > </bindings> > Actually don’t waste your time on this alias option. PeristenceUnitServiceHandler’s approach to names will prevent it from working. — Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -- Hälsningar, Martin Andersson Purple Scout AB +46 732 05 14 01

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(a)redhat.com&gt; 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(a)redhat.com >> <mailto:smarlow@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... >> >> 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(a)redhat.com >> <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org >> <mailto:wildfly-dev@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that’s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU? —E On 31 Jan 2014, at 15:05, Scott Marlow <smarlow(a)redhat.com&gt; 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). > > If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround. 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). > > 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). > > @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten. > > IMO, we should address these problems in the standards (EE specs). 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(a)redhat.com&gt; 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(a)redhat.com >>>> <mailto:smarlow@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... >>>> >>>> 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(a)redhat.com >>>> <mailto:smarlow@redhat.com> >>>>> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>> <mailto:wildfly-dev@lists.jboss.org >>>> <mailto:wildfly-dev@lists.jboss.org>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >

That is something that should be fixed, since it does not supports JNDI Federation or link refs. A lookup should be done, and this should be achieved by using a LookupResourceInjection, not MSC services directly. But that’s not everything I guess, if we want to support java:comp in PUs properly, then I see no other way than looking up the concrete datasource when the entity manager is provided to the app. —E On 31 Jan 2014, at 15:55, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > No, since we aren't doing a JNDI lookup, instead the persistence unit service has a dependency on the DataSource. > > https://github.com/wildfly/wildfly/blob/master/jpa/core/src/main/java/org... shows how we use ContextNames.bindInfoForEnvEntry(). > > On 01/31/2014 10:37 AM, Eduardo Martins wrote: >> Do you need the concrete Datasource resource present in JNDI at that JPA Entity class enhancing/rewriting? If that’s the case, then what if you have a PU pointing to java:comp/env/MyDatasource, inside an EJB jar with 2 EJBs, where each binds java:comp/env/MyDatasource to different concrete Datasource, which concrete Datasource will be used by the PU? >> >> —E >> >> On 31 Jan 2014, at 15:05, Scott Marlow <smarlow(a)redhat.com&gt; 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). >>> >>> If the ResourceReferenceProcessor ran early enough, the hint wouldn't be needed as a workaround. 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). >>> >>> 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). >>> >>> @DataSourceDefinition are also not available until Phase.INSTALL, so they cannot be used with applications that expect entities to be enhanced/rewritten. >>> >>> IMO, we should address these problems in the standards (EE specs). 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(a)redhat.com&gt; 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(a)redhat.com >>>>>> <mailto:smarlow@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... >>>>>> >>>>>> 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(a)redhat.com >>>>>> <mailto:smarlow@redhat.com> >>>>>>> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>>>> <mailto:wildfly-dev@lists.jboss.org >>>>>> <mailto:wildfly-dev@lists.jboss.org>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >> >

On Jan 31, 2014, at 9:05 AM, Scott Marlow <smarlow(a)redhat.com&gt; 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 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.

> > @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.

> > 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.

> 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(a)redhat.com&gt; 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(a)redhat.com >>>> <mailto:smarlow@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... >>>> >>>> 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(a)redhat.com >>>> <mailto:smarlow@redhat.com> >>>>> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>> <mailto:wildfly-dev@lists.jboss.org >>>> <mailto:wildfly-dev@lists.jboss.org>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)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

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(a)redhat.com&gt; 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(a)redhat.com >> <mailto:smarlow@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... >> >> 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(a)redhat.com >> <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@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... >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org >> <mailto:wildfly-dev@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Yes, but design wise this should be done at EAR level, preventing the mistake of multiple components trying to bind same entry in java:app.

Yes, but design wise this should be done at EAR level, preventing the mistake of multiple components trying to bind same entry in java:app.