He is part of the expert group, one of the lead of openwebbeans implementation and tomee comitter.
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 18:35 GMT+01:00 COURTAULT Francois < [email protected]>: > Hello Romain, > > Thanks a lot for this useful exchange :-) > > BTW, who is Mark Struberg ? member of the CDI expert group ? member of > Java EE expert group ? member of another JCP ? > > Best Regards. > > -----Original Message----- > From: Romain Manni-Bucau [mailto:[email protected]] > Sent: mardi 19 janvier 2016 18:30 > To: [email protected] > Subject: Re: CDI behavior change: who is right ? > > 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. > > > ________________________________ > 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. >
