We tried that initially (few years ago now) and the JNDI lookup didn't
work as the DataSource service was not started. Will the java:comp jndi
lookup work in the FIRST_MODULE_USE phase?
On 01/31/2014 11:07 AM, Eduardo Martins wrote:
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> 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> 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> 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
>>>>
>>>
>>
>