2016-01-19 18:08 GMT+01:00 COURTAULT Francois < [email protected]>:
> Hello Romain, > > Understood but it's Java EE provider implementation choice (eg the fact > that ear libraries and ejb modules are sharing the same CDI visibility > isolated from webapps), right ? > Nothing clearly written in any Java EE spec, right ? > > yep > So to summarize what is currently implemented in TomEE: > CDI events sent by a war are visible/observable by ear libraries and > ejb modules, right ? > CDI events sent by ear libraries and ejb modules aren't > visible/observable by wars, right ? > > yep > The only thing that puzzle me a little bit is that regarding the class > visibility, according to the spec, all java ee modules classes in an ear > are accessible/visible from any class belonging to those modules. But it > seems that for CDI context/visibility nothing is clearly written in any > CDI/Java EE specs and above all, the CDI context/visibility is not aligned > with class visibility in any Java EE spec :-( > > yep agree, you can speak of it to Mark (Struberg) ;) > Best Regards. > > -----Original Message----- > From: Romain Manni-Bucau [mailto:[email protected]] > Sent: mardi 19 janvier 2016 17:40 > To: [email protected] > Subject: Re: CDI behavior change: who is right ? > > 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. > > > ________________________________ > 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. >
