[wildfly-dev] How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
arjan tijms
arjan.tijms at gmail.com
Fri Jan 31 11:17:22 EST 2014
On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins at redhat.com>wrote:
> Sure, all you said is correct, I just said that ideally java:app bindings
> should be done at app level, and provide the reasoning behind that.
>
Indeed, but then if there's only ever a war then web.xml is at the app
level, and java:app bindings can be set without architectural concerns in
web.xml, can't they?
>
> --E
>
> On 31 Jan 2014, at 15:58, arjan tijms <arjan.tijms at gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins at redhat.com>wrote:
>
>> 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.
>>
>
> Is that really true if there only ever is the .war? E.g. in the sense as
> mentioned by Adam here:
> http://adam-bien.com/roller/abien/entry/is_java_ee_6_war
>
> Also, don't EJBs inside a .war share java:comp with the web module's
> single java:comp? So the entire concept of EJB beans having their own
> component namespace just goes away then. I think in the modern usage
> pattern of EJBs there's not much use for this anyway. If the CDI bean model
> effectively replaces the EJB component model in some future Java EE release
> then all of this is surely history.
>
> Effectively, in a pure web application (.war, no .ear involved) java:comp
> is effectively java:module, which should be more straightforward to
> resolve, shouldn't it?
>
>
>
>
>
>
>
>>
>> --E
>>
>> On 31 Jan 2014, at 15:08, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins at redhat.com>wrote:
>>
>>> or use an ear and define a java:app bind at application.xml, to be
>>> shared by all modules and components?
>>>
>>
>> If you have just a .war, you can use java:app just as well, can't you? I
>> don't think there's a specific need to use an ear just for java:app.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>>>
>>> --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
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140131/d6b243bc/attachment.html
More information about the wildfly-dev
mailing list