Hello Romain,
Thanks again for your reply.
But the issue I have on my side is: What do you mean by ear-lib ? Is it the lib
folder at the ear root folder for example?
In my package I have the following schema if my above assumption is right (eg
ear-lib means what is located under the lib folder in the ear) :
[ear lib]
/ /|\ \
/ | \
/ | \
/ | \
/ | \
[webapp1] <----> [ejb1] <----> [webapp2] (According to the Java EE 6 spec §EE
8.3 Class Loading Requirement)
/\ /\
|____________________________|
REST endpoint in Webapp1 calls a stateless ejb in ejb1 which fires a CDI event
which is observed by a @Singleton @Startup ejb in webapp2.
Using this deployment: the CDI event is not received by webapp2 :-(
If I replace webapp2 by ejb2 (@Singleton @Startup in there): the CDI event is
received !
So, BTW you don't explain to me why it works if we use an ejb module instead of
a war module (eg I don't see the link with ear-lib you mentioned).
Best Regards.
-----Original Message-----
From: Romain Manni-Bucau [mailto:[email protected]]
Sent: mardi 19 janvier 2016 16:24
To: [email protected]
Subject: Re: CDI behavior change: who is right ?
hmm let's try to make it simple:
[ear lib]
.
/|\
|
|
[webapp]
webapp can see ear-lib classes but ear-lib can't see webapp classes.
for CDI it is the same: webapp can fire events to ear-lib but ear-lib doesnt
fire events to webapp.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-01-19 16:20 GMT+01:00 COURTAULT Francois <
[email protected]>:
> Hello Romain,
>
> Not sure to have understood what you tried to explain to me but thanks
> for your answer.
>
> But according to my knowledge, per spec Java EE 6 §EE 8.3 Class
> Loading Requirement, war modules classes and ejb modules classes
> embedded in a single ear are visible and accessible from any classes
> belonging to these modules, right ?
>
> So, in my use case, when the Stateless EJB, in ejb1.jar embedded in
> myear.ear, fires a CDI event this one should be consumed by the
> Observer (@Singleton @Startup) embedded in a war, war1.war embedded in
> myear.ear, because all the classes in those modules are
> accessible/visible from the others, right ?
>
> I have also performed the following test: this time, the Observer
> (@Singleton @Startup) is embedded in a separate ejb module (ejb2.jar
> embedded in myear.ear). In this case, then the event is received by
> the Observer.
>
> So why TomEE+ and Weblogic has a different behavior whether the
> Observer is embedded in an ejb module or a war module ?
> Any explanation ?
>
> Best Regards.
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:[email protected]]
> Sent: mardi 19 janvier 2016 14:42
> To: [email protected]
> Subject: Re: CDI behavior change: who is right ?
>
> Hi Francois,
>
> "I have looked at the spec and I haven't seen something saying that
> the CDI event couldn't be received if the observer is packaged in war
> itself embedded in an ear."
>
> specifications work the opposite way. If you didnt find it then it is
> not specified and up to the implementation. Said otherwise wildfly is
> not right but is not wrong and same for tomee.
>
> IIRC TomEE propagates events from webapp to ear-libs part but the
> opposite is avoided - we are aligned on classloaders to avoid to leak
> informations.
> The EJB should use the ear-lib classloader by spec so it would be
> weird to leak the event in the webapp by design. I agree you can say
> it is under a request so we could find it - technically it is true and
> easy - but then take into account @Asynchronous, concurrency-utilities
> and simply hierarchy model and reusing the request is really no more
> obvious - personally I fight to not reuse it to keep the application
> understandable.
>
> I know wildfly has a "flat" mode but from experience we chose the less
> broken solution to stay friendly with deltaspike and codi to cite a few.
>
> ear and CDI is highly under specified and portability there needs some
> carefulness.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog <
> http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <
> http://www.tomitribe.com>
>
> 2016-01-19 14:31 GMT+01:00 COURTAULT Francois <
> [email protected]>:
>
> > Hello everyone,
> >
> > Let me describe the test I have performed :
> > REST endpoint/Stateless EJB packaged in a war calls a Stateless
> > EJB packaged in an ejb-jar, this one send/fire a CDI event. A
> > Singleton EJB annotated @Startup packaged in war has a
> > method which observes this event. All this wars and ejb-jar
> > are embedded in an ear.
> >
> > This test has been performed on Wildfly 9.0.1, Weblogic 12.1.3 and
> > TomEE+
> > 1.7.3 and the results are:
> >
> > - Weblogic 12.1.3 and TomEE+ 1.7.3: no event is received by the
> > Singleton packaged in a war when we trigger the REST endpoint with a
> > GET
> >
> > - Wildfly 9.0.1: event is received by the Singleton packaged in
> a
> > war when we trigger the REST endpoint with a GET
> >
> > I have looked at the spec and I haven't seen something saying that
> > the CDI event couldn't be received if the observer is packaged in
> > war itself embedded in an ear.
> > So my guess is that Wildfly has the right behavior and there is an
> > issue on TomEE+ 1.7.3 and Weblogic 12.1.3: do you confirm or not ?
> > If you think that Wildfly behavior is wrong, then, could you please
> > mention an extract of the CDI specification which explains that clearly ?
> >
> > Best Regards.
> > ________________________________
> > This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any
> > unauthorized use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be
> > liable for the message if altered, changed or falsified. If you are
> > not the intended recipient of this message, please delete it and
> > notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> ________________________________
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>
________________________________
This message and any attachments are intended solely for the addressees and
may contain confidential information. Any unauthorized use or disclosure,
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the
message if altered, changed or falsified. If you are not the intended recipient
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free
from viruses, the sender will not be liable for damages caused by a transmitted
virus.
