> > He is part of the expert group, one of the lead of openwebbeans > implementation and tomee comitter.
…and the guy who tries to get EAR and CDI aligned a bit. There are quite a few things mismatched when it comes to CDI and modularity. To make things more complicated, different vendors did choose to integrate EARs totally different. I’ve written up a few facts and findings in a blog post: https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ Plus the classloading is not defined at all in EARs atm. It’s a bit like ’should be visible’ without defining any defaults right now. E.g. all /lib/*.jar are defined as one module. Each ejb-jar is defined as one module. And modules are isolated per ‚recommendation‘. But I’ve seen no single container holding true to this. All containers I know serve those jars with the same ClassLoader, thus witout isolation. We tried to get an agreement on this in the EE EG, but it isn’t yet public. Back to your question: Technically we could imo easily use the TCCL instead of the module classloader to detect the proper BeanManager to use for firing CDI events. Currently we default to the module BeanManager. Which is not the worst decision. Just has a few pros and cons. That said it’s sometimes probably broken to deliver a CDI event from a webapp to the shared ‚parent EAR classloader‘ and sometimes it’s bad to do it the other way. Case a.) Consider an interface X with implementation ClassA implements X in the shared ear lib. Now add ClassB implements X in one WAR of the ear. The public void catchX(@Observes X x) stores away X in a cache and delivers it to other WARs. Bad luck if you em.fire(new ClassB()); Depending on the actual use case this could blow up badly with a NoClassDefFound… Case b.) Same is true in the opposite direction if you have the observer in the WAR and the payload is something like this public class CollectorEvent { private Set<ClassX> collectedXItems = new HashSet<>(); public void add(X newItem) { collectedXItems.add(newItem);} and the WAR has an @Observes CollectorEvent and adds a new ClassB() Could go boom as well, right? It’s pretty late over here and I tried to keep it short. Just reply if some explanation was too vague. LieGrue, strub PS: the same can happen if you have a simple hashmap or a manual observer/observable situation. Famous example was the facelet cache of the jsf RI in older versions. Did blew up in ears quite nastily. The question is how good do we try to prevent such things and how much restrictions does this create. > Am 19.01.2016 um 18:36 schrieb Romain Manni-Bucau <[email protected]>: > > 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. >>
