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 ?
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 ?
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 :-(
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.
