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.
