ear-lib (ear libraries) and ejbmodules are sharing the same CDI visibility isolated from webapps. Webapps see this CDI context but not the opposite as described.
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 17:16 GMT+01:00 COURTAULT Francois < [email protected]>: > 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. >
