Re: [wildfly-dev] How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
10:17 a.m.
On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
Hi,
On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins(a)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(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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
10:20 a.m.
New subject: How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
I think in that case you should use java:module, what if you later put that war in a ear
with other modules? IMHO you should use the proper scope of each standard JNDI context.
—E
On 31 Jan 2014, at 16:17, arjan tijms <arjan.tijms(a)gmail.com> wrote:
On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins <emartins(a)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(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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
10:33 a.m.
New subject: How to deal with resource refs when deploying JPA container managed entity managers (WFLY-2841)
On Fri, Jan 31, 2014 at 5:20 PM, Eduardo Martins <emartins(a)redhat.com>wrote:
I think in that case you should use java:module, what if you later
put
that war in a ear with other modules? IMHO you should use the proper scope
of each standard JNDI context.
It may depend strongly on the architecture of the module. If the .war in
question was very strictly designed following the "war is the new ear"
paradigm (so to speak), then it may be clear that it won't ever be put into
an ear later.
I practice I found it to be relatively rare that an application is designed
as a war one, then later put inside an ear with some other modules and that
you just expect everything to work. Things like @ApplicationScoped and CDI
extensions unfortunately don't play well here. The concept of what
constitutes an "application" is not entirely consistently defined in Java
EE.
IMHO you design an *application* as either war or ear, and if you want to
put an application implemented as a war inside an ear later on there's
likely some refactoring to take into account. Occasionally you may design
something as being a web *module* from the start, even when not yet
embedded into an ear, but as said from personal experience I found this to
be relatively rare.
--E
On 31 Jan 2014, at 16:17, arjan tijms <arjan.tijms(a)gmail.com> wrote:
On Fri, Jan 31, 2014 at 5:11 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 31, 2014 at 4:45 PM, Eduardo Martins <emartins(a)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(a)gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Jan 31, 2014 at 3:03 PM, Eduardo Martins
<emartins(a)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(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
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>
>
3977
days inactive
3977
days old
2 comments
2 participants
participants (2)
-
arjan tijms -
Eduardo Martins