You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Eric Covener <co...@gmail.com> on 2010/06/15 12:21:03 UTC
problems with lack of archive-centric BeanManager
Currently the OWB BeanManager does not retain much info about
individual Archives (whether they be BDA's or non-BDA's), only the
aggregate classes and beanXML's.
For the sake of discussion, consider a WAR with three utility jar's in
the lib/ directory.
a.jar is a BDA that defines an interceptor binding and an interceptor
b.jar is a BDA that defines a managed bean with the aforementioned
InterceptorBinding
c.jar is a BDA that defines a managed bean with the aforementioned
InterceptorBinding.
Our current design does not permit either of the following scenarions, AFAICT:
b.jar and c.jar both enable the interceptor defined in a.jar
(treated as a duplicate)
Exactly one of b.jar and c.jar enables the interceptor defined in
a.jar (ends up enabled for beans from either archive if enabled in one
-- this is in the more troubling neighborhood)
This is primarily because between the BeanManager and the
ScannerService, we lose all granularity abut the source of classes and
beanXML's. This manifests itself in slightly more involved ways, such
as when an applications contains multiple modules with multiple
classloaders. Neither 1 BeanManager or N BeanManagers seems too
appealing in this case.
There has been some offline discussion about:
* introduce a first-class data structure to represent a Archive
(composed of classes, XML's, and Archive references)
* teach the ScannService or some successor to return lists of
Archives to the deployment code
* teach the BeanManager to manage a network of Archives to properly
follow the EE accessibility rules
I took a crack at illustrating this on top of guess by adding separate
sub-modules for the utility jars as described above
http://people.apache.org/~covener/owb/
OOTB this results in a disabled (for a specific bean based on the BDA
it comes from ) interceptor being run.
--
Eric Covener
covener@gmail.com
Re: problems with lack of archive-centric BeanManager
Posted by Joseph Bergmark <be...@apache.org>.
I think there are possibly two issues being discussed concurrently here, and
both are important.
1) What does the spec really say about BDAs: It seems we all agree that
according to the spec, multiple jars w/ beans.xml inside of a war are
multiple BDAs and we need to support enabling decorators, interceptors an
alternatives on a BDA by BDA basis to be compliant with the spec.
2) What do we think about the choices the spec made: We can take use this
in at least two ways. We can provide feedback back to the EG, and we can
provide what we believe are better options in OWB.
Personally I'm in favor of making the default OWB behavior match the spec,
and then providing properties that turn on other behaviors that might be
considered more reasonable in some scenarios (alternatives is probably a
really good example).
Sincerely,
Joe
On Tue, Jun 22, 2010 at 3:12 AM, Mark Struberg <st...@yahoo.de> wrote:
> > those classes are visible to the WAR/EAR/JAR
> > etc. according to the classloader rules.
>
> The classes for sure, but not the <alternatives> etc according to some
> JBoss guys who reread the spec. See section 12.1
>
> > The WEB-INF/classes directory of a war is a bean archive if there is a
> > file named beans.xml in the WEB-INF directory of the war.
>
> Which means the term BDA for a WAR only affects the WEB-INF/classes
> directory and _not_ subsequently all the libs in WEB-INF/lib! This is also
> confirmed by JBoss guys.
>
> Eric yesterday also pointed me to section 5.1 or the spec:
>
> > An alternative is not available for injection, lookup or EL resolution
> > to classes or JSP/JSF pages in a module unless the
> > module is a bean archive and the alternative is explicitly selected in
> > that bean archive. An alternative is never available for
> > injection, lookup or EL resolution in a module that is not a bean
> > archive.
>
>
> But this definition is _completely_ sick from a real world apps view!
>
>
> I'm still in favour of providing an 'order' attribute to <interceptors
> order="3">, <alternatives> and <decorators> sections which defines the
> 'importance' of a definition.
> Higher importance means that it gets applied later, and thus overriding
> previous settings. With this trick you could easily define the final
> ordering for your interceptors in the beans.xml of your WAR by simply
> writing <interceptors order="100">...
>
> LieGrue,
> strub
>
> --- On Tue, 6/22/10, Gurkan Erdogdu <gu...@yahoo.com> wrote:
>
> > From: Gurkan Erdogdu <gu...@yahoo.com>
> > Subject: Re: problems with lack of archive-centric BeanManager
> > To: dev@openwebbeans.apache.org
> > Date: Tuesday, June 22, 2010, 5:38 AM
> > >>>>..... it just
> > shouldn't automatically get the
> > >>>>decorators, interceptors & alternatives
> > enabled that other BDA.
> >
> > I think this is not correct behaviour. Spec. clearly
> > defines that interceptors, decorators and alternatives are
> > enabled by the bean archive's bean.xml. Therefore, if those
> > ar enabled, those classes are visible to the WAR/EAR/JAR
> > etc. according to the classloader rules.
> >
> >
> > For OWB Case
> > --------------------
> > In our case, we collect all beans.xml and classes
> > regardless of BDA's and setup
> > interceptors/decorators/alternatives. I think this is not a
> > correct behaviour. As Eric already has shown us
> >
> > if you put X.jar into WEB-INF/lib with disabled interceptor
> > in its beans.xml but you enable it in WEB-INF/beans.xml, OWB
> > enables the interceptor and this is not correct regarding
> > the spec.
> >
> >
> > Thanks;
> >
> > --Gurkan
> >
> >
> > ________________________________
> > From: Joseph Bergmark <be...@apache.org>
> > To: dev@openwebbeans.apache.org
> > Sent: Tue, June 22, 2010 12:08:19 AM
> > Subject: Re: problems with lack of archive-centric
> > BeanManager
> >
> > I explicitly pointed out 12.1 in my e-mail earlier today
> > and I agree that is
> > the key section.
> >
> > If it is a good idea or not is important and is feedback we
> > should probably
> > probably take back to the EG, but implementation wise don't
> > we basically
> > have to implement the spec as it is defined now, possibly
> > with properties to
> > give non-default behavior if desired?
> >
> > I think this really only affects enabled decorators,
> > interceptors and
> > alternatives. If 1 BDA has class loader visibility
> > into another BDA it can
> > still inject those classes, it just shouldn't automatically
> > get the
> > decorators, interceptors & alternatives enabled that
> > other BDA.
> >
> > Sincerely,
> >
> > Joe
> >
> >
> > On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <st...@yahoo.de>
> > wrote:
> >
> > > Folks, please reread section 12.1 of the spec (first
> > bullet list).
> > >
> > > According to this spec section, any jar with a
> > beans.xml is an OWN bean
> > > archive.
> > >
> > > So if any section in the spec is talking about a
> > certain functionality
> > > should only work in the bean archive the configuration
> > is done in, then all
> > > other jars are not affected. And this is imo not a
> > good idea...
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > --- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com>
> > wrote:
> > >
> > > > From: Gurkan Erdogdu <gu...@yahoo.com>
> > > > Subject: Re: problems with lack of
> > archive-centric BeanManager
> > > > To: dev@openwebbeans.apache.org
> > > > Date: Monday, June 21, 2010, 3:59 PM
> > > >
> > > > >>>What would happen if your WAR files
> > do NOT
> > > > contain those jars, but they
> > > > are part of the EAR and shared between ALL WARs?
> > > > If those jars are visible to WARs then they can
> > be injected
> > > > into WARs. Point is the visibility of the classes
> > regarding
> > > > to modules. If those JARs are put into EAR/lib
> > folder, and
> > > > those jars contains META-INF/beans.xml, all of
> > them are
> > > > visible to all WARs and EJBs and RARs.
> > > >
> > > >
> > > > >>>And thus the interceptors,
> > alternatives and all
> > > > this stuff simply WONT
> > > > WORK?
> > > > I think they work.
> > > >
> > > > --Gurkan
> > > >
> > > >
> > > > ________________________________
> > > > From: Mark Struberg <st...@yahoo.de>
> > > > To: dev@openwebbeans.apache.org
> > > > Sent: Mon, June 21, 2010 6:09:23 PM
> > > > Subject: Re: problems with lack of
> > archive-centric
> > > > BeanManager
> > > >
> > > > oki, take it one step further.
> > > >
> > > > What would happen if your WAR files do NOT
> > contain those
> > > > jars, but they are part of the EAR and shared
> > between ALL
> > > > WARs?
> > > >
> > > > Then (according to the definition in the spec)
> > those JARs
> > > > are _not_ part of the WARs BDA, isn't?
> > > >
> > > > And thus the interceptors, alternatives and all
> > this stuff
> > > > simply WONT WORK?
> > > >
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> > > > wrote:
> > > >
> > > > > From: Joseph Bergmark <be...@apache.org>
> > > > > Subject: Re: problems with lack of
> > archive-centric
> > > > BeanManager
> > > > > To: dev@openwebbeans.apache.org
> > > > > Date: Monday, June 21, 2010, 3:00 PM
> > > > > I'm not entirely sure I agree that
> > > > > BDAs are only centered around EE
> > > > > classloader rules. For example in
> > section 12.1
> > > > where
> > > > > it talks about
> > > > > deployment rules:
> > > > >
> > > > > "
> > > > > In an application deployed as a war, the
> > container
> > > > searches
> > > > > every bean
> > > > > deployment archive bundled with or
> > referenced
> > > > > by the war. The bean deployment archives
> > might be
> > > > library
> > > > > jars or the
> > > > > WEB-INF/classes directory.
> > > > > "
> > > > >
> > > > > This is a simple war case, but the spec
> > talks about
> > > > > searching "every" bda
> > > > > and "bean deployment archives". I
> > interpret
> > > > "library
> > > > > jars" here to mean jar
> > > > > files in the lib directory of the war, which
> > in OWB
> > > > we
> > > > > treat as part of one
> > > > > big "bda" including the war itself.
> > > > >
> > > > > As far as Mark's point about the TCK, I
> > think there
> > > > may be
> > > > > holes in the
> > > > > TCK. For example we passed the
> > Decorator tests
> > > > before
> > > > > we ever had support
> > > > > for Abstract Decorators, despite that being
> > pretty
> > > > clearly
> > > > > declared as an
> > > > > option in section 8.1.3.
> > > > >
> > > > > Would you be against investigating code that
> > keeps
> > > > track of
> > > > > which BDAs (in
> > > > > the war case I mean jars or WEB-INF/classes
> > > > directories)
> > > > > beans were found
> > > > > in, and then using that information during
> > > > > interceptor/decorator/alternative
> > > > > resolution? If nothing else it might
> > segue
> > > > nicely
> > > > > into WAR + EJB scenarios
> > > > > later.
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > Joe
> > > > >
> > > > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan
> > Erdogdu <
> > > gurkanerdogdu@yahoo.com>wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Currently OWB has not implemented the
> > BDA
> > > > related
> > > > > semantic. BDAs are
> > > > > > related with the Java EE classloader
> > rules. For
> > > > > example, if you have a EAR
> > > > > > file with EJB and WAR, then EAR will
> > have bean
> > > > > deployment archive that
> > > > > > contains two other BDAs.
> > > > > >
> > > > > > EAR BDA --> WAR BDA + EJB BDA
> > > > > >
> > > > > > But EJB BDA does not see the WAR BDA
> > archive. But
> > > > both
> > > > > of them see the
> > > > > > common BDA that is located in anywhere
> > in the
> > > > > Application Server ClassPath,
> > > > > > META-INF/Mainifest.MF ClassPath etc.
> > > > > >
> > > > > > In summary, BDA is written to work with
> > current
> > > > Java
> > > > > EE classloader
> > > > > > semantics. You can look at Java EE
> > specification
> > > > > version 6 section "EE 8.3
> > > > > > ClasLoading Requirements" to get
> > how
> > > > classloader
> > > > > works.
> > > > > >
> > > > > >
> > > > > > Currently OWB does not support BDAs.
> > > > Because we
> > > > > do not integrate the OWB
> > > > > > with full profie Java EE server.
> > > > > >
> > > > > > This is an one area that OWB needs
> > contribution.
> > > > > >
> > > > > > I hope this clears the discussion;
> > > > > >
> > > > > > --Gurkan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Eric Covener <co...@gmail.com>
> > > > > > To: dev@openwebbeans.apache.org
> > > > > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > > > > Subject: Re: problems with lack of
> > > > archive-centric
> > > > > BeanManager
> > > > > >
> > > > > > On Mon, Jun 21, 2010 at 7:53 AM, Mark
> > Struberg
> > > > <st...@yahoo.de>
> > > > > wrote:
> > > > > > > you picked a good example:
> > > > > > >
> > > > > > >> | 2.6. Alternatives
> > > > > > >> | An alternative is a bean
> > that must be
> > > > > explicitly declared
> > > > > > >> in the
> > > > > > >> beans.xml file if it should be
> > available
> > > > for
> > > > > lookup,
> > > > > > >> injection or EL resolution.
> > > > > > >
> > > > > > > There is _nothing_ stated if this
> > > > alternative
> > > > > bean should a) only be
> > > > > > available for this specific bean
> > archive it is
> > > > defined
> > > > > in or if it b) should
> > > > > > be available for _all_ bean archives.
> > > > > > >
> > > > > > > Imo a) would make absolutely no
> > sense, so
> > > > it
> > > > > clearly is b). This is imo
> > > > > > also what weld is doing. But for some
> > weird
> > > > reason
> > > > > Gavin is arguing in
> > > > > > exactly the opposite when it comes to
> > > > interceptors -
> > > > > despite the wording in
> > > > > > the spec is exactly the same there...
> > > > > > >
> > > > > >
> > > > > > In the modularity section:
> > > > > >
> > > > > > An alternative is not available for
> > injection,
> > > > lookup
> > > > > or EL resolution
> > > > > > to classes or JSP/JSF pages in a module
> > unless
> > > > the
> > > > > module is a bean
> > > > > > archive
> > > > > > ___and the alternative is explicitly
> > selected in
> > > > that
> > > > > bean archive____
> > > > > >
> > > > > >
> > > > > > There is IMO an option C that is a
> > pretty
> > > > reasonable
> > > > > behavior
> > > > > >
> > > > > > Assume a WAR with three bean archives.
> > > > > >
> > > > > > bda1.jar contains a bean that also has
> > an
> > > > > alternative.
> > > > > > bda2.jar has no enabled alternatives
> > > > > > bda3.jar has the alternative enabled.
> > > > > >
> > > > > > Injection into beans from bda2 behave
> > differently
> > > > than
> > > > > injections into
> > > > > > beans from bda2.
> > > > > >
> > > > > > The biggest confusion for me here is
> > the way that
> > > > 299
> > > > > tries to define
> > > > > > a WAR + beans.xml as something
> > different than
> > > > just a
> > > > > BDA in section 5,
> > > > > > without going so far as to actually
> > saying it
> > > > really
> > > > > is intended to
> > > > > > behave differently (relative to BDA's
> > "inside"
> > > > of
> > > > > it).
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eric Covener
> > > > > > covener@gmail.com
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
> those classes are visible to the WAR/EAR/JAR
> etc. according to the classloader rules.
The classes for sure, but not the <alternatives> etc according to some JBoss guys who reread the spec. See section 12.1
> The WEB-INF/classes directory of a war is a bean archive if there is a
> file named beans.xml in the WEB-INF directory of the war.
Which means the term BDA for a WAR only affects the WEB-INF/classes directory and _not_ subsequently all the libs in WEB-INF/lib! This is also confirmed by JBoss guys.
Eric yesterday also pointed me to section 5.1 or the spec:
> An alternative is not available for injection, lookup or EL resolution
> to classes or JSP/JSF pages in a module unless the
> module is a bean archive and the alternative is explicitly selected in
> that bean archive. An alternative is never available for
> injection, lookup or EL resolution in a module that is not a bean
> archive.
But this definition is _completely_ sick from a real world apps view!
I'm still in favour of providing an 'order' attribute to <interceptors order="3">, <alternatives> and <decorators> sections which defines the 'importance' of a definition.
Higher importance means that it gets applied later, and thus overriding previous settings. With this trick you could easily define the final ordering for your interceptors in the beans.xml of your WAR by simply writing <interceptors order="100">...
LieGrue,
strub
--- On Tue, 6/22/10, Gurkan Erdogdu <gu...@yahoo.com> wrote:
> From: Gurkan Erdogdu <gu...@yahoo.com>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Tuesday, June 22, 2010, 5:38 AM
> >>>>..... it just
> shouldn't automatically get the
> >>>>decorators, interceptors & alternatives
> enabled that other BDA.
>
> I think this is not correct behaviour. Spec. clearly
> defines that interceptors, decorators and alternatives are
> enabled by the bean archive's bean.xml. Therefore, if those
> ar enabled, those classes are visible to the WAR/EAR/JAR
> etc. according to the classloader rules.
>
>
> For OWB Case
> --------------------
> In our case, we collect all beans.xml and classes
> regardless of BDA's and setup
> interceptors/decorators/alternatives. I think this is not a
> correct behaviour. As Eric already has shown us
>
> if you put X.jar into WEB-INF/lib with disabled interceptor
> in its beans.xml but you enable it in WEB-INF/beans.xml, OWB
> enables the interceptor and this is not correct regarding
> the spec.
>
>
> Thanks;
>
> --Gurkan
>
>
> ________________________________
> From: Joseph Bergmark <be...@apache.org>
> To: dev@openwebbeans.apache.org
> Sent: Tue, June 22, 2010 12:08:19 AM
> Subject: Re: problems with lack of archive-centric
> BeanManager
>
> I explicitly pointed out 12.1 in my e-mail earlier today
> and I agree that is
> the key section.
>
> If it is a good idea or not is important and is feedback we
> should probably
> probably take back to the EG, but implementation wise don't
> we basically
> have to implement the spec as it is defined now, possibly
> with properties to
> give non-default behavior if desired?
>
> I think this really only affects enabled decorators,
> interceptors and
> alternatives. If 1 BDA has class loader visibility
> into another BDA it can
> still inject those classes, it just shouldn't automatically
> get the
> decorators, interceptors & alternatives enabled that
> other BDA.
>
> Sincerely,
>
> Joe
>
>
> On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <st...@yahoo.de>
> wrote:
>
> > Folks, please reread section 12.1 of the spec (first
> bullet list).
> >
> > According to this spec section, any jar with a
> beans.xml is an OWN bean
> > archive.
> >
> > So if any section in the spec is talking about a
> certain functionality
> > should only work in the bean archive the configuration
> is done in, then all
> > other jars are not affected. And this is imo not a
> good idea...
> >
> > LieGrue,
> > strub
> >
> >
> > --- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com>
> wrote:
> >
> > > From: Gurkan Erdogdu <gu...@yahoo.com>
> > > Subject: Re: problems with lack of
> archive-centric BeanManager
> > > To: dev@openwebbeans.apache.org
> > > Date: Monday, June 21, 2010, 3:59 PM
> > >
> > > >>>What would happen if your WAR files
> do NOT
> > > contain those jars, but they
> > > are part of the EAR and shared between ALL WARs?
> > > If those jars are visible to WARs then they can
> be injected
> > > into WARs. Point is the visibility of the classes
> regarding
> > > to modules. If those JARs are put into EAR/lib
> folder, and
> > > those jars contains META-INF/beans.xml, all of
> them are
> > > visible to all WARs and EJBs and RARs.
> > >
> > >
> > > >>>And thus the interceptors,
> alternatives and all
> > > this stuff simply WONT
> > > WORK?
> > > I think they work.
> > >
> > > --Gurkan
> > >
> > >
> > > ________________________________
> > > From: Mark Struberg <st...@yahoo.de>
> > > To: dev@openwebbeans.apache.org
> > > Sent: Mon, June 21, 2010 6:09:23 PM
> > > Subject: Re: problems with lack of
> archive-centric
> > > BeanManager
> > >
> > > oki, take it one step further.
> > >
> > > What would happen if your WAR files do NOT
> contain those
> > > jars, but they are part of the EAR and shared
> between ALL
> > > WARs?
> > >
> > > Then (according to the definition in the spec)
> those JARs
> > > are _not_ part of the WARs BDA, isn't?
> > >
> > > And thus the interceptors, alternatives and all
> this stuff
> > > simply WONT WORK?
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > > --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> > > wrote:
> > >
> > > > From: Joseph Bergmark <be...@apache.org>
> > > > Subject: Re: problems with lack of
> archive-centric
> > > BeanManager
> > > > To: dev@openwebbeans.apache.org
> > > > Date: Monday, June 21, 2010, 3:00 PM
> > > > I'm not entirely sure I agree that
> > > > BDAs are only centered around EE
> > > > classloader rules. For example in
> section 12.1
> > > where
> > > > it talks about
> > > > deployment rules:
> > > >
> > > > "
> > > > In an application deployed as a war, the
> container
> > > searches
> > > > every bean
> > > > deployment archive bundled with or
> referenced
> > > > by the war. The bean deployment archives
> might be
> > > library
> > > > jars or the
> > > > WEB-INF/classes directory.
> > > > "
> > > >
> > > > This is a simple war case, but the spec
> talks about
> > > > searching "every" bda
> > > > and "bean deployment archives". I
> interpret
> > > "library
> > > > jars" here to mean jar
> > > > files in the lib directory of the war, which
> in OWB
> > > we
> > > > treat as part of one
> > > > big "bda" including the war itself.
> > > >
> > > > As far as Mark's point about the TCK, I
> think there
> > > may be
> > > > holes in the
> > > > TCK. For example we passed the
> Decorator tests
> > > before
> > > > we ever had support
> > > > for Abstract Decorators, despite that being
> pretty
> > > clearly
> > > > declared as an
> > > > option in section 8.1.3.
> > > >
> > > > Would you be against investigating code that
> keeps
> > > track of
> > > > which BDAs (in
> > > > the war case I mean jars or WEB-INF/classes
> > > directories)
> > > > beans were found
> > > > in, and then using that information during
> > > > interceptor/decorator/alternative
> > > > resolution? If nothing else it might
> segue
> > > nicely
> > > > into WAR + EJB scenarios
> > > > later.
> > > >
> > > > Sincerely,
> > > >
> > > > Joe
> > > >
> > > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan
> Erdogdu <
> > gurkanerdogdu@yahoo.com>wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Currently OWB has not implemented the
> BDA
> > > related
> > > > semantic. BDAs are
> > > > > related with the Java EE classloader
> rules. For
> > > > example, if you have a EAR
> > > > > file with EJB and WAR, then EAR will
> have bean
> > > > deployment archive that
> > > > > contains two other BDAs.
> > > > >
> > > > > EAR BDA --> WAR BDA + EJB BDA
> > > > >
> > > > > But EJB BDA does not see the WAR BDA
> archive. But
> > > both
> > > > of them see the
> > > > > common BDA that is located in anywhere
> in the
> > > > Application Server ClassPath,
> > > > > META-INF/Mainifest.MF ClassPath etc.
> > > > >
> > > > > In summary, BDA is written to work with
> current
> > > Java
> > > > EE classloader
> > > > > semantics. You can look at Java EE
> specification
> > > > version 6 section "EE 8.3
> > > > > ClasLoading Requirements" to get
> how
> > > classloader
> > > > works.
> > > > >
> > > > >
> > > > > Currently OWB does not support BDAs.
> > > Because we
> > > > do not integrate the OWB
> > > > > with full profie Java EE server.
> > > > >
> > > > > This is an one area that OWB needs
> contribution.
> > > > >
> > > > > I hope this clears the discussion;
> > > > >
> > > > > --Gurkan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Eric Covener <co...@gmail.com>
> > > > > To: dev@openwebbeans.apache.org
> > > > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > > > Subject: Re: problems with lack of
> > > archive-centric
> > > > BeanManager
> > > > >
> > > > > On Mon, Jun 21, 2010 at 7:53 AM, Mark
> Struberg
> > > <st...@yahoo.de>
> > > > wrote:
> > > > > > you picked a good example:
> > > > > >
> > > > > >> | 2.6. Alternatives
> > > > > >> | An alternative is a bean
> that must be
> > > > explicitly declared
> > > > > >> in the
> > > > > >> beans.xml file if it should be
> available
> > > for
> > > > lookup,
> > > > > >> injection or EL resolution.
> > > > > >
> > > > > > There is _nothing_ stated if this
> > > alternative
> > > > bean should a) only be
> > > > > available for this specific bean
> archive it is
> > > defined
> > > > in or if it b) should
> > > > > be available for _all_ bean archives.
> > > > > >
> > > > > > Imo a) would make absolutely no
> sense, so
> > > it
> > > > clearly is b). This is imo
> > > > > also what weld is doing. But for some
> weird
> > > reason
> > > > Gavin is arguing in
> > > > > exactly the opposite when it comes to
> > > interceptors -
> > > > despite the wording in
> > > > > the spec is exactly the same there...
> > > > > >
> > > > >
> > > > > In the modularity section:
> > > > >
> > > > > An alternative is not available for
> injection,
> > > lookup
> > > > or EL resolution
> > > > > to classes or JSP/JSF pages in a module
> unless
> > > the
> > > > module is a bean
> > > > > archive
> > > > > ___and the alternative is explicitly
> selected in
> > > that
> > > > bean archive____
> > > > >
> > > > >
> > > > > There is IMO an option C that is a
> pretty
> > > reasonable
> > > > behavior
> > > > >
> > > > > Assume a WAR with three bean archives.
> > > > >
> > > > > bda1.jar contains a bean that also has
> an
> > > > alternative.
> > > > > bda2.jar has no enabled alternatives
> > > > > bda3.jar has the alternative enabled.
> > > > >
> > > > > Injection into beans from bda2 behave
> differently
> > > than
> > > > injections into
> > > > > beans from bda2.
> > > > >
> > > > > The biggest confusion for me here is
> the way that
> > > 299
> > > > tries to define
> > > > > a WAR + beans.xml as something
> different than
> > > just a
> > > > BDA in section 5,
> > > > > without going so far as to actually
> saying it
> > > really
> > > > is intended to
> > > > > behave differently (relative to BDA's
> "inside"
> > > of
> > > > it).
> > > > >
> > > > >
> > > > > --
> > > > > Eric Covener
> > > > > covener@gmail.com
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>>..... it just shouldn't automatically get the
>>>>decorators, interceptors & alternatives enabled that other BDA.
I think this is not correct behaviour. Spec. clearly defines that interceptors, decorators and alternatives are enabled by the bean archive's bean.xml. Therefore, if those ar enabled, those classes are visible to the WAR/EAR/JAR etc. according to the classloader rules.
For OWB Case
--------------------
In our case, we collect all beans.xml and classes regardless of BDA's and setup interceptors/decorators/alternatives. I think this is not a correct behaviour. As Eric already has shown us
if you put X.jar into WEB-INF/lib with disabled interceptor in its beans.xml but you enable it in WEB-INF/beans.xml, OWB enables the interceptor and this is not correct regarding the spec.
Thanks;
--Gurkan
________________________________
From: Joseph Bergmark <be...@apache.org>
To: dev@openwebbeans.apache.org
Sent: Tue, June 22, 2010 12:08:19 AM
Subject: Re: problems with lack of archive-centric BeanManager
I explicitly pointed out 12.1 in my e-mail earlier today and I agree that is
the key section.
If it is a good idea or not is important and is feedback we should probably
probably take back to the EG, but implementation wise don't we basically
have to implement the spec as it is defined now, possibly with properties to
give non-default behavior if desired?
I think this really only affects enabled decorators, interceptors and
alternatives. If 1 BDA has class loader visibility into another BDA it can
still inject those classes, it just shouldn't automatically get the
decorators, interceptors & alternatives enabled that other BDA.
Sincerely,
Joe
On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <st...@yahoo.de> wrote:
> Folks, please reread section 12.1 of the spec (first bullet list).
>
> According to this spec section, any jar with a beans.xml is an OWN bean
> archive.
>
> So if any section in the spec is talking about a certain functionality
> should only work in the bean archive the configuration is done in, then all
> other jars are not affected. And this is imo not a good idea...
>
> LieGrue,
> strub
>
>
> --- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com> wrote:
>
> > From: Gurkan Erdogdu <gu...@yahoo.com>
> > Subject: Re: problems with lack of archive-centric BeanManager
> > To: dev@openwebbeans.apache.org
> > Date: Monday, June 21, 2010, 3:59 PM
> >
> > >>>What would happen if your WAR files do NOT
> > contain those jars, but they
> > are part of the EAR and shared between ALL WARs?
> > If those jars are visible to WARs then they can be injected
> > into WARs. Point is the visibility of the classes regarding
> > to modules. If those JARs are put into EAR/lib folder, and
> > those jars contains META-INF/beans.xml, all of them are
> > visible to all WARs and EJBs and RARs.
> >
> >
> > >>>And thus the interceptors, alternatives and all
> > this stuff simply WONT
> > WORK?
> > I think they work.
> >
> > --Gurkan
> >
> >
> > ________________________________
> > From: Mark Struberg <st...@yahoo.de>
> > To: dev@openwebbeans.apache.org
> > Sent: Mon, June 21, 2010 6:09:23 PM
> > Subject: Re: problems with lack of archive-centric
> > BeanManager
> >
> > oki, take it one step further.
> >
> > What would happen if your WAR files do NOT contain those
> > jars, but they are part of the EAR and shared between ALL
> > WARs?
> >
> > Then (according to the definition in the spec) those JARs
> > are _not_ part of the WARs BDA, isn't?
> >
> > And thus the interceptors, alternatives and all this stuff
> > simply WONT WORK?
> >
> >
> > LieGrue,
> > strub
> >
> > --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> > wrote:
> >
> > > From: Joseph Bergmark <be...@apache.org>
> > > Subject: Re: problems with lack of archive-centric
> > BeanManager
> > > To: dev@openwebbeans.apache.org
> > > Date: Monday, June 21, 2010, 3:00 PM
> > > I'm not entirely sure I agree that
> > > BDAs are only centered around EE
> > > classloader rules. For example in section 12.1
> > where
> > > it talks about
> > > deployment rules:
> > >
> > > "
> > > In an application deployed as a war, the container
> > searches
> > > every bean
> > > deployment archive bundled with or referenced
> > > by the war. The bean deployment archives might be
> > library
> > > jars or the
> > > WEB-INF/classes directory.
> > > "
> > >
> > > This is a simple war case, but the spec talks about
> > > searching "every" bda
> > > and "bean deployment archives". I interpret
> > "library
> > > jars" here to mean jar
> > > files in the lib directory of the war, which in OWB
> > we
> > > treat as part of one
> > > big "bda" including the war itself.
> > >
> > > As far as Mark's point about the TCK, I think there
> > may be
> > > holes in the
> > > TCK. For example we passed the Decorator tests
> > before
> > > we ever had support
> > > for Abstract Decorators, despite that being pretty
> > clearly
> > > declared as an
> > > option in section 8.1.3.
> > >
> > > Would you be against investigating code that keeps
> > track of
> > > which BDAs (in
> > > the war case I mean jars or WEB-INF/classes
> > directories)
> > > beans were found
> > > in, and then using that information during
> > > interceptor/decorator/alternative
> > > resolution? If nothing else it might segue
> > nicely
> > > into WAR + EJB scenarios
> > > later.
> > >
> > > Sincerely,
> > >
> > > Joe
> > >
> > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <
> gurkanerdogdu@yahoo.com>wrote:
> > >
> > > > Hello,
> > > >
> > > > Currently OWB has not implemented the BDA
> > related
> > > semantic. BDAs are
> > > > related with the Java EE classloader rules. For
> > > example, if you have a EAR
> > > > file with EJB and WAR, then EAR will have bean
> > > deployment archive that
> > > > contains two other BDAs.
> > > >
> > > > EAR BDA --> WAR BDA + EJB BDA
> > > >
> > > > But EJB BDA does not see the WAR BDA archive. But
> > both
> > > of them see the
> > > > common BDA that is located in anywhere in the
> > > Application Server ClassPath,
> > > > META-INF/Mainifest.MF ClassPath etc.
> > > >
> > > > In summary, BDA is written to work with current
> > Java
> > > EE classloader
> > > > semantics. You can look at Java EE specification
> > > version 6 section "EE 8.3
> > > > ClasLoading Requirements" to get how
> > classloader
> > > works.
> > > >
> > > >
> > > > Currently OWB does not support BDAs.
> > Because we
> > > do not integrate the OWB
> > > > with full profie Java EE server.
> > > >
> > > > This is an one area that OWB needs contribution.
> > > >
> > > > I hope this clears the discussion;
> > > >
> > > > --Gurkan
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Eric Covener <co...@gmail.com>
> > > > To: dev@openwebbeans.apache.org
> > > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > > Subject: Re: problems with lack of
> > archive-centric
> > > BeanManager
> > > >
> > > > On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg
> > <st...@yahoo.de>
> > > wrote:
> > > > > you picked a good example:
> > > > >
> > > > >> | 2.6. Alternatives
> > > > >> | An alternative is a bean that must be
> > > explicitly declared
> > > > >> in the
> > > > >> beans.xml file if it should be available
> > for
> > > lookup,
> > > > >> injection or EL resolution.
> > > > >
> > > > > There is _nothing_ stated if this
> > alternative
> > > bean should a) only be
> > > > available for this specific bean archive it is
> > defined
> > > in or if it b) should
> > > > be available for _all_ bean archives.
> > > > >
> > > > > Imo a) would make absolutely no sense, so
> > it
> > > clearly is b). This is imo
> > > > also what weld is doing. But for some weird
> > reason
> > > Gavin is arguing in
> > > > exactly the opposite when it comes to
> > interceptors -
> > > despite the wording in
> > > > the spec is exactly the same there...
> > > > >
> > > >
> > > > In the modularity section:
> > > >
> > > > An alternative is not available for injection,
> > lookup
> > > or EL resolution
> > > > to classes or JSP/JSF pages in a module unless
> > the
> > > module is a bean
> > > > archive
> > > > ___and the alternative is explicitly selected in
> > that
> > > bean archive____
> > > >
> > > >
> > > > There is IMO an option C that is a pretty
> > reasonable
> > > behavior
> > > >
> > > > Assume a WAR with three bean archives.
> > > >
> > > > bda1.jar contains a bean that also has an
> > > alternative.
> > > > bda2.jar has no enabled alternatives
> > > > bda3.jar has the alternative enabled.
> > > >
> > > > Injection into beans from bda2 behave differently
> > than
> > > injections into
> > > > beans from bda2.
> > > >
> > > > The biggest confusion for me here is the way that
> > 299
> > > tries to define
> > > > a WAR + beans.xml as something different than
> > just a
> > > BDA in section 5,
> > > > without going so far as to actually saying it
> > really
> > > is intended to
> > > > behave differently (relative to BDA's "inside"
> > of
> > > it).
> > > >
> > > >
> > > > --
> > > > Eric Covener
> > > > covener@gmail.com
> > > >
> > > >
> > > >
> > >
> >
> >
>
>
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
I agree that we could _easily_ implement this. But what practical use case would that be? You would basically _NOT_ be able to define an alternative for your system without having to modify and repackage ALL the jars where the alternative should get picked up (in most applications simply ALL your jars). Imo - even if technically possible - this makes absolutely no sense...
LieGrue,
strub
--- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org> wrote:
> From: Joseph Bergmark <be...@apache.org>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 9:08 PM
> I explicitly pointed out 12.1 in my
> e-mail earlier today and I agree that is
> the key section.
>
> If it is a good idea or not is important and is feedback we
> should probably
> probably take back to the EG, but implementation wise don't
> we basically
> have to implement the spec as it is defined now, possibly
> with properties to
> give non-default behavior if desired?
>
> I think this really only affects enabled decorators,
> interceptors and
> alternatives. If 1 BDA has class loader visibility
> into another BDA it can
> still inject those classes, it just shouldn't automatically
> get the
> decorators, interceptors & alternatives enabled that
> other BDA.
>
> Sincerely,
>
> Joe
>
>
> On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <st...@yahoo.de>
> wrote:
>
> > Folks, please reread section 12.1 of the spec (first
> bullet list).
> >
> > According to this spec section, any jar with a
> beans.xml is an OWN bean
> > archive.
> >
> > So if any section in the spec is talking about a
> certain functionality
> > should only work in the bean archive the configuration
> is done in, then all
> > other jars are not affected. And this is imo not a
> good idea...
> >
> > LieGrue,
> > strub
> >
> >
> > --- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com>
> wrote:
> >
> > > From: Gurkan Erdogdu <gu...@yahoo.com>
> > > Subject: Re: problems with lack of
> archive-centric BeanManager
> > > To: dev@openwebbeans.apache.org
> > > Date: Monday, June 21, 2010, 3:59 PM
> > >
> > > >>>What would happen if your WAR files
> do NOT
> > > contain those jars, but they
> > > are part of the EAR and shared between ALL WARs?
> > > If those jars are visible to WARs then they can
> be injected
> > > into WARs. Point is the visibility of the classes
> regarding
> > > to modules. If those JARs are put into EAR/lib
> folder, and
> > > those jars contains META-INF/beans.xml, all of
> them are
> > > visible to all WARs and EJBs and RARs.
> > >
> > >
> > > >>>And thus the interceptors,
> alternatives and all
> > > this stuff simply WONT
> > > WORK?
> > > I think they work.
> > >
> > > --Gurkan
> > >
> > >
> > > ________________________________
> > > From: Mark Struberg <st...@yahoo.de>
> > > To: dev@openwebbeans.apache.org
> > > Sent: Mon, June 21, 2010 6:09:23 PM
> > > Subject: Re: problems with lack of
> archive-centric
> > > BeanManager
> > >
> > > oki, take it one step further.
> > >
> > > What would happen if your WAR files do NOT
> contain those
> > > jars, but they are part of the EAR and shared
> between ALL
> > > WARs?
> > >
> > > Then (according to the definition in the spec)
> those JARs
> > > are _not_ part of the WARs BDA, isn't?
> > >
> > > And thus the interceptors, alternatives and all
> this stuff
> > > simply WONT WORK?
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > > --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> > > wrote:
> > >
> > > > From: Joseph Bergmark <be...@apache.org>
> > > > Subject: Re: problems with lack of
> archive-centric
> > > BeanManager
> > > > To: dev@openwebbeans.apache.org
> > > > Date: Monday, June 21, 2010, 3:00 PM
> > > > I'm not entirely sure I agree that
> > > > BDAs are only centered around EE
> > > > classloader rules. For example in
> section 12.1
> > > where
> > > > it talks about
> > > > deployment rules:
> > > >
> > > > "
> > > > In an application deployed as a war, the
> container
> > > searches
> > > > every bean
> > > > deployment archive bundled with or
> referenced
> > > > by the war. The bean deployment archives
> might be
> > > library
> > > > jars or the
> > > > WEB-INF/classes directory.
> > > > "
> > > >
> > > > This is a simple war case, but the spec
> talks about
> > > > searching "every" bda
> > > > and "bean deployment archives". I
> interpret
> > > "library
> > > > jars" here to mean jar
> > > > files in the lib directory of the war, which
> in OWB
> > > we
> > > > treat as part of one
> > > > big "bda" including the war itself.
> > > >
> > > > As far as Mark's point about the TCK, I
> think there
> > > may be
> > > > holes in the
> > > > TCK. For example we passed the
> Decorator tests
> > > before
> > > > we ever had support
> > > > for Abstract Decorators, despite that being
> pretty
> > > clearly
> > > > declared as an
> > > > option in section 8.1.3.
> > > >
> > > > Would you be against investigating code that
> keeps
> > > track of
> > > > which BDAs (in
> > > > the war case I mean jars or WEB-INF/classes
> > > directories)
> > > > beans were found
> > > > in, and then using that information during
> > > > interceptor/decorator/alternative
> > > > resolution? If nothing else it might
> segue
> > > nicely
> > > > into WAR + EJB scenarios
> > > > later.
> > > >
> > > > Sincerely,
> > > >
> > > > Joe
> > > >
> > > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan
> Erdogdu <
> > gurkanerdogdu@yahoo.com>wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Currently OWB has not implemented the
> BDA
> > > related
> > > > semantic. BDAs are
> > > > > related with the Java EE classloader
> rules. For
> > > > example, if you have a EAR
> > > > > file with EJB and WAR, then EAR will
> have bean
> > > > deployment archive that
> > > > > contains two other BDAs.
> > > > >
> > > > > EAR BDA --> WAR BDA + EJB BDA
> > > > >
> > > > > But EJB BDA does not see the WAR BDA
> archive. But
> > > both
> > > > of them see the
> > > > > common BDA that is located in anywhere
> in the
> > > > Application Server ClassPath,
> > > > > META-INF/Mainifest.MF ClassPath etc.
> > > > >
> > > > > In summary, BDA is written to work with
> current
> > > Java
> > > > EE classloader
> > > > > semantics. You can look at Java EE
> specification
> > > > version 6 section "EE 8.3
> > > > > ClasLoading Requirements" to get
> how
> > > classloader
> > > > works.
> > > > >
> > > > >
> > > > > Currently OWB does not support BDAs.
> > > Because we
> > > > do not integrate the OWB
> > > > > with full profie Java EE server.
> > > > >
> > > > > This is an one area that OWB needs
> contribution.
> > > > >
> > > > > I hope this clears the discussion;
> > > > >
> > > > > --Gurkan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Eric Covener <co...@gmail.com>
> > > > > To: dev@openwebbeans.apache.org
> > > > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > > > Subject: Re: problems with lack of
> > > archive-centric
> > > > BeanManager
> > > > >
> > > > > On Mon, Jun 21, 2010 at 7:53 AM, Mark
> Struberg
> > > <st...@yahoo.de>
> > > > wrote:
> > > > > > you picked a good example:
> > > > > >
> > > > > >> | 2.6. Alternatives
> > > > > >> | An alternative is a bean
> that must be
> > > > explicitly declared
> > > > > >> in the
> > > > > >> beans.xml file if it should be
> available
> > > for
> > > > lookup,
> > > > > >> injection or EL resolution.
> > > > > >
> > > > > > There is _nothing_ stated if this
> > > alternative
> > > > bean should a) only be
> > > > > available for this specific bean
> archive it is
> > > defined
> > > > in or if it b) should
> > > > > be available for _all_ bean archives.
> > > > > >
> > > > > > Imo a) would make absolutely no
> sense, so
> > > it
> > > > clearly is b). This is imo
> > > > > also what weld is doing. But for some
> weird
> > > reason
> > > > Gavin is arguing in
> > > > > exactly the opposite when it comes to
> > > interceptors -
> > > > despite the wording in
> > > > > the spec is exactly the same there...
> > > > > >
> > > > >
> > > > > In the modularity section:
> > > > >
> > > > > An alternative is not available for
> injection,
> > > lookup
> > > > or EL resolution
> > > > > to classes or JSP/JSF pages in a module
> unless
> > > the
> > > > module is a bean
> > > > > archive
> > > > > ___and the alternative is explicitly
> selected in
> > > that
> > > > bean archive____
> > > > >
> > > > >
> > > > > There is IMO an option C that is a
> pretty
> > > reasonable
> > > > behavior
> > > > >
> > > > > Assume a WAR with three bean archives.
> > > > >
> > > > > bda1.jar contains a bean that also has
> an
> > > > alternative.
> > > > > bda2.jar has no enabled alternatives
> > > > > bda3.jar has the alternative enabled.
> > > > >
> > > > > Injection into beans from bda2 behave
> differently
> > > than
> > > > injections into
> > > > > beans from bda2.
> > > > >
> > > > > The biggest confusion for me here is
> the way that
> > > 299
> > > > tries to define
> > > > > a WAR + beans.xml as something
> different than
> > > just a
> > > > BDA in section 5,
> > > > > without going so far as to actually
> saying it
> > > really
> > > > is intended to
> > > > > behave differently (relative to BDA's
> "inside"
> > > of
> > > > it).
> > > > >
> > > > >
> > > > > --
> > > > > Eric Covener
> > > > > covener@gmail.com
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
Re: problems with lack of archive-centric BeanManager
Posted by Joseph Bergmark <be...@apache.org>.
I explicitly pointed out 12.1 in my e-mail earlier today and I agree that is
the key section.
If it is a good idea or not is important and is feedback we should probably
probably take back to the EG, but implementation wise don't we basically
have to implement the spec as it is defined now, possibly with properties to
give non-default behavior if desired?
I think this really only affects enabled decorators, interceptors and
alternatives. If 1 BDA has class loader visibility into another BDA it can
still inject those classes, it just shouldn't automatically get the
decorators, interceptors & alternatives enabled that other BDA.
Sincerely,
Joe
On Mon, Jun 21, 2010 at 4:53 PM, Mark Struberg <st...@yahoo.de> wrote:
> Folks, please reread section 12.1 of the spec (first bullet list).
>
> According to this spec section, any jar with a beans.xml is an OWN bean
> archive.
>
> So if any section in the spec is talking about a certain functionality
> should only work in the bean archive the configuration is done in, then all
> other jars are not affected. And this is imo not a good idea...
>
> LieGrue,
> strub
>
>
> --- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com> wrote:
>
> > From: Gurkan Erdogdu <gu...@yahoo.com>
> > Subject: Re: problems with lack of archive-centric BeanManager
> > To: dev@openwebbeans.apache.org
> > Date: Monday, June 21, 2010, 3:59 PM
> >
> > >>>What would happen if your WAR files do NOT
> > contain those jars, but they
> > are part of the EAR and shared between ALL WARs?
> > If those jars are visible to WARs then they can be injected
> > into WARs. Point is the visibility of the classes regarding
> > to modules. If those JARs are put into EAR/lib folder, and
> > those jars contains META-INF/beans.xml, all of them are
> > visible to all WARs and EJBs and RARs.
> >
> >
> > >>>And thus the interceptors, alternatives and all
> > this stuff simply WONT
> > WORK?
> > I think they work.
> >
> > --Gurkan
> >
> >
> > ________________________________
> > From: Mark Struberg <st...@yahoo.de>
> > To: dev@openwebbeans.apache.org
> > Sent: Mon, June 21, 2010 6:09:23 PM
> > Subject: Re: problems with lack of archive-centric
> > BeanManager
> >
> > oki, take it one step further.
> >
> > What would happen if your WAR files do NOT contain those
> > jars, but they are part of the EAR and shared between ALL
> > WARs?
> >
> > Then (according to the definition in the spec) those JARs
> > are _not_ part of the WARs BDA, isn't?
> >
> > And thus the interceptors, alternatives and all this stuff
> > simply WONT WORK?
> >
> >
> > LieGrue,
> > strub
> >
> > --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> > wrote:
> >
> > > From: Joseph Bergmark <be...@apache.org>
> > > Subject: Re: problems with lack of archive-centric
> > BeanManager
> > > To: dev@openwebbeans.apache.org
> > > Date: Monday, June 21, 2010, 3:00 PM
> > > I'm not entirely sure I agree that
> > > BDAs are only centered around EE
> > > classloader rules. For example in section 12.1
> > where
> > > it talks about
> > > deployment rules:
> > >
> > > "
> > > In an application deployed as a war, the container
> > searches
> > > every bean
> > > deployment archive bundled with or referenced
> > > by the war. The bean deployment archives might be
> > library
> > > jars or the
> > > WEB-INF/classes directory.
> > > "
> > >
> > > This is a simple war case, but the spec talks about
> > > searching "every" bda
> > > and "bean deployment archives". I interpret
> > "library
> > > jars" here to mean jar
> > > files in the lib directory of the war, which in OWB
> > we
> > > treat as part of one
> > > big "bda" including the war itself.
> > >
> > > As far as Mark's point about the TCK, I think there
> > may be
> > > holes in the
> > > TCK. For example we passed the Decorator tests
> > before
> > > we ever had support
> > > for Abstract Decorators, despite that being pretty
> > clearly
> > > declared as an
> > > option in section 8.1.3.
> > >
> > > Would you be against investigating code that keeps
> > track of
> > > which BDAs (in
> > > the war case I mean jars or WEB-INF/classes
> > directories)
> > > beans were found
> > > in, and then using that information during
> > > interceptor/decorator/alternative
> > > resolution? If nothing else it might segue
> > nicely
> > > into WAR + EJB scenarios
> > > later.
> > >
> > > Sincerely,
> > >
> > > Joe
> > >
> > > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <
> gurkanerdogdu@yahoo.com>wrote:
> > >
> > > > Hello,
> > > >
> > > > Currently OWB has not implemented the BDA
> > related
> > > semantic. BDAs are
> > > > related with the Java EE classloader rules. For
> > > example, if you have a EAR
> > > > file with EJB and WAR, then EAR will have bean
> > > deployment archive that
> > > > contains two other BDAs.
> > > >
> > > > EAR BDA --> WAR BDA + EJB BDA
> > > >
> > > > But EJB BDA does not see the WAR BDA archive. But
> > both
> > > of them see the
> > > > common BDA that is located in anywhere in the
> > > Application Server ClassPath,
> > > > META-INF/Mainifest.MF ClassPath etc.
> > > >
> > > > In summary, BDA is written to work with current
> > Java
> > > EE classloader
> > > > semantics. You can look at Java EE specification
> > > version 6 section "EE 8.3
> > > > ClasLoading Requirements" to get how
> > classloader
> > > works.
> > > >
> > > >
> > > > Currently OWB does not support BDAs.
> > Because we
> > > do not integrate the OWB
> > > > with full profie Java EE server.
> > > >
> > > > This is an one area that OWB needs contribution.
> > > >
> > > > I hope this clears the discussion;
> > > >
> > > > --Gurkan
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Eric Covener <co...@gmail.com>
> > > > To: dev@openwebbeans.apache.org
> > > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > > Subject: Re: problems with lack of
> > archive-centric
> > > BeanManager
> > > >
> > > > On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg
> > <st...@yahoo.de>
> > > wrote:
> > > > > you picked a good example:
> > > > >
> > > > >> | 2.6. Alternatives
> > > > >> | An alternative is a bean that must be
> > > explicitly declared
> > > > >> in the
> > > > >> beans.xml file if it should be available
> > for
> > > lookup,
> > > > >> injection or EL resolution.
> > > > >
> > > > > There is _nothing_ stated if this
> > alternative
> > > bean should a) only be
> > > > available for this specific bean archive it is
> > defined
> > > in or if it b) should
> > > > be available for _all_ bean archives.
> > > > >
> > > > > Imo a) would make absolutely no sense, so
> > it
> > > clearly is b). This is imo
> > > > also what weld is doing. But for some weird
> > reason
> > > Gavin is arguing in
> > > > exactly the opposite when it comes to
> > interceptors -
> > > despite the wording in
> > > > the spec is exactly the same there...
> > > > >
> > > >
> > > > In the modularity section:
> > > >
> > > > An alternative is not available for injection,
> > lookup
> > > or EL resolution
> > > > to classes or JSP/JSF pages in a module unless
> > the
> > > module is a bean
> > > > archive
> > > > ___and the alternative is explicitly selected in
> > that
> > > bean archive____
> > > >
> > > >
> > > > There is IMO an option C that is a pretty
> > reasonable
> > > behavior
> > > >
> > > > Assume a WAR with three bean archives.
> > > >
> > > > bda1.jar contains a bean that also has an
> > > alternative.
> > > > bda2.jar has no enabled alternatives
> > > > bda3.jar has the alternative enabled.
> > > >
> > > > Injection into beans from bda2 behave differently
> > than
> > > injections into
> > > > beans from bda2.
> > > >
> > > > The biggest confusion for me here is the way that
> > 299
> > > tries to define
> > > > a WAR + beans.xml as something different than
> > just a
> > > BDA in section 5,
> > > > without going so far as to actually saying it
> > really
> > > is intended to
> > > > behave differently (relative to BDA's "inside"
> > of
> > > it).
> > > >
> > > >
> > > > --
> > > > Eric Covener
> > > > covener@gmail.com
> > > >
> > > >
> > > >
> > >
> >
> >
>
>
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
Folks, please reread section 12.1 of the spec (first bullet list).
According to this spec section, any jar with a beans.xml is an OWN bean archive.
So if any section in the spec is talking about a certain functionality should only work in the bean archive the configuration is done in, then all other jars are not affected. And this is imo not a good idea...
LieGrue,
strub
--- On Mon, 6/21/10, Gurkan Erdogdu <gu...@yahoo.com> wrote:
> From: Gurkan Erdogdu <gu...@yahoo.com>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 3:59 PM
>
> >>>What would happen if your WAR files do NOT
> contain those jars, but they
> are part of the EAR and shared between ALL WARs?
> If those jars are visible to WARs then they can be injected
> into WARs. Point is the visibility of the classes regarding
> to modules. If those JARs are put into EAR/lib folder, and
> those jars contains META-INF/beans.xml, all of them are
> visible to all WARs and EJBs and RARs.
>
>
> >>>And thus the interceptors, alternatives and all
> this stuff simply WONT
> WORK?
> I think they work.
>
> --Gurkan
>
>
> ________________________________
> From: Mark Struberg <st...@yahoo.de>
> To: dev@openwebbeans.apache.org
> Sent: Mon, June 21, 2010 6:09:23 PM
> Subject: Re: problems with lack of archive-centric
> BeanManager
>
> oki, take it one step further.
>
> What would happen if your WAR files do NOT contain those
> jars, but they are part of the EAR and shared between ALL
> WARs?
>
> Then (according to the definition in the spec) those JARs
> are _not_ part of the WARs BDA, isn't?
>
> And thus the interceptors, alternatives and all this stuff
> simply WONT WORK?
>
>
> LieGrue,
> strub
>
> --- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org>
> wrote:
>
> > From: Joseph Bergmark <be...@apache.org>
> > Subject: Re: problems with lack of archive-centric
> BeanManager
> > To: dev@openwebbeans.apache.org
> > Date: Monday, June 21, 2010, 3:00 PM
> > I'm not entirely sure I agree that
> > BDAs are only centered around EE
> > classloader rules. For example in section 12.1
> where
> > it talks about
> > deployment rules:
> >
> > "
> > In an application deployed as a war, the container
> searches
> > every bean
> > deployment archive bundled with or referenced
> > by the war. The bean deployment archives might be
> library
> > jars or the
> > WEB-INF/classes directory.
> > "
> >
> > This is a simple war case, but the spec talks about
> > searching "every" bda
> > and "bean deployment archives". I interpret
> "library
> > jars" here to mean jar
> > files in the lib directory of the war, which in OWB
> we
> > treat as part of one
> > big "bda" including the war itself.
> >
> > As far as Mark's point about the TCK, I think there
> may be
> > holes in the
> > TCK. For example we passed the Decorator tests
> before
> > we ever had support
> > for Abstract Decorators, despite that being pretty
> clearly
> > declared as an
> > option in section 8.1.3.
> >
> > Would you be against investigating code that keeps
> track of
> > which BDAs (in
> > the war case I mean jars or WEB-INF/classes
> directories)
> > beans were found
> > in, and then using that information during
> > interceptor/decorator/alternative
> > resolution? If nothing else it might segue
> nicely
> > into WAR + EJB scenarios
> > later.
> >
> > Sincerely,
> >
> > Joe
> >
> > On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <gu...@yahoo.com>wrote:
> >
> > > Hello,
> > >
> > > Currently OWB has not implemented the BDA
> related
> > semantic. BDAs are
> > > related with the Java EE classloader rules. For
> > example, if you have a EAR
> > > file with EJB and WAR, then EAR will have bean
> > deployment archive that
> > > contains two other BDAs.
> > >
> > > EAR BDA --> WAR BDA + EJB BDA
> > >
> > > But EJB BDA does not see the WAR BDA archive. But
> both
> > of them see the
> > > common BDA that is located in anywhere in the
> > Application Server ClassPath,
> > > META-INF/Mainifest.MF ClassPath etc.
> > >
> > > In summary, BDA is written to work with current
> Java
> > EE classloader
> > > semantics. You can look at Java EE specification
> > version 6 section "EE 8.3
> > > ClasLoading Requirements" to get how
> classloader
> > works.
> > >
> > >
> > > Currently OWB does not support BDAs.
> Because we
> > do not integrate the OWB
> > > with full profie Java EE server.
> > >
> > > This is an one area that OWB needs contribution.
> > >
> > > I hope this clears the discussion;
> > >
> > > --Gurkan
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Eric Covener <co...@gmail.com>
> > > To: dev@openwebbeans.apache.org
> > > Sent: Mon, June 21, 2010 3:45:02 PM
> > > Subject: Re: problems with lack of
> archive-centric
> > BeanManager
> > >
> > > On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg
> <st...@yahoo.de>
> > wrote:
> > > > you picked a good example:
> > > >
> > > >> | 2.6. Alternatives
> > > >> | An alternative is a bean that must be
> > explicitly declared
> > > >> in the
> > > >> beans.xml file if it should be available
> for
> > lookup,
> > > >> injection or EL resolution.
> > > >
> > > > There is _nothing_ stated if this
> alternative
> > bean should a) only be
> > > available for this specific bean archive it is
> defined
> > in or if it b) should
> > > be available for _all_ bean archives.
> > > >
> > > > Imo a) would make absolutely no sense, so
> it
> > clearly is b). This is imo
> > > also what weld is doing. But for some weird
> reason
> > Gavin is arguing in
> > > exactly the opposite when it comes to
> interceptors -
> > despite the wording in
> > > the spec is exactly the same there...
> > > >
> > >
> > > In the modularity section:
> > >
> > > An alternative is not available for injection,
> lookup
> > or EL resolution
> > > to classes or JSP/JSF pages in a module unless
> the
> > module is a bean
> > > archive
> > > ___and the alternative is explicitly selected in
> that
> > bean archive____
> > >
> > >
> > > There is IMO an option C that is a pretty
> reasonable
> > behavior
> > >
> > > Assume a WAR with three bean archives.
> > >
> > > bda1.jar contains a bean that also has an
> > alternative.
> > > bda2.jar has no enabled alternatives
> > > bda3.jar has the alternative enabled.
> > >
> > > Injection into beans from bda2 behave differently
> than
> > injections into
> > > beans from bda2.
> > >
> > > The biggest confusion for me here is the way that
> 299
> > tries to define
> > > a WAR + beans.xml as something different than
> just a
> > BDA in section 5,
> > > without going so far as to actually saying it
> really
> > is intended to
> > > behave differently (relative to BDA's "inside"
> of
> > it).
> > >
> > >
> > > --
> > > Eric Covener
> > > covener@gmail.com
> > >
> > >
> > >
> >
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>What would happen if your WAR files do NOT contain those jars, but they
are part of the EAR and shared between ALL WARs?
If those jars are visible to WARs then they can be injected into WARs. Point is the visibility of the classes regarding to modules. If those JARs are put into EAR/lib folder, and those jars contains META-INF/beans.xml, all of them are visible to all WARs and EJBs and RARs.
>>>And thus the interceptors, alternatives and all this stuff simply WONT
WORK?
I think they work.
--Gurkan
________________________________
From: Mark Struberg <st...@yahoo.de>
To: dev@openwebbeans.apache.org
Sent: Mon, June 21, 2010 6:09:23 PM
Subject: Re: problems with lack of archive-centric BeanManager
oki, take it one step further.
What would happen if your WAR files do NOT contain those jars, but they are part of the EAR and shared between ALL WARs?
Then (according to the definition in the spec) those JARs are _not_ part of the WARs BDA, isn't?
And thus the interceptors, alternatives and all this stuff simply WONT WORK?
LieGrue,
strub
--- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org> wrote:
> From: Joseph Bergmark <be...@apache.org>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 3:00 PM
> I'm not entirely sure I agree that
> BDAs are only centered around EE
> classloader rules. For example in section 12.1 where
> it talks about
> deployment rules:
>
> "
> In an application deployed as a war, the container searches
> every bean
> deployment archive bundled with or referenced
> by the war. The bean deployment archives might be library
> jars or the
> WEB-INF/classes directory.
> "
>
> This is a simple war case, but the spec talks about
> searching "every" bda
> and "bean deployment archives". I interpret "library
> jars" here to mean jar
> files in the lib directory of the war, which in OWB we
> treat as part of one
> big "bda" including the war itself.
>
> As far as Mark's point about the TCK, I think there may be
> holes in the
> TCK. For example we passed the Decorator tests before
> we ever had support
> for Abstract Decorators, despite that being pretty clearly
> declared as an
> option in section 8.1.3.
>
> Would you be against investigating code that keeps track of
> which BDAs (in
> the war case I mean jars or WEB-INF/classes directories)
> beans were found
> in, and then using that information during
> interceptor/decorator/alternative
> resolution? If nothing else it might segue nicely
> into WAR + EJB scenarios
> later.
>
> Sincerely,
>
> Joe
>
> On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <gu...@yahoo.com>wrote:
>
> > Hello,
> >
> > Currently OWB has not implemented the BDA related
> semantic. BDAs are
> > related with the Java EE classloader rules. For
> example, if you have a EAR
> > file with EJB and WAR, then EAR will have bean
> deployment archive that
> > contains two other BDAs.
> >
> > EAR BDA --> WAR BDA + EJB BDA
> >
> > But EJB BDA does not see the WAR BDA archive. But both
> of them see the
> > common BDA that is located in anywhere in the
> Application Server ClassPath,
> > META-INF/Mainifest.MF ClassPath etc.
> >
> > In summary, BDA is written to work with current Java
> EE classloader
> > semantics. You can look at Java EE specification
> version 6 section "EE 8.3
> > ClasLoading Requirements" to get how classloader
> works.
> >
> >
> > Currently OWB does not support BDAs. Because we
> do not integrate the OWB
> > with full profie Java EE server.
> >
> > This is an one area that OWB needs contribution.
> >
> > I hope this clears the discussion;
> >
> > --Gurkan
> >
> >
> >
> >
> > ________________________________
> > From: Eric Covener <co...@gmail.com>
> > To: dev@openwebbeans.apache.org
> > Sent: Mon, June 21, 2010 3:45:02 PM
> > Subject: Re: problems with lack of archive-centric
> BeanManager
> >
> > On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> > > you picked a good example:
> > >
> > >> | 2.6. Alternatives
> > >> | An alternative is a bean that must be
> explicitly declared
> > >> in the
> > >> beans.xml file if it should be available for
> lookup,
> > >> injection or EL resolution.
> > >
> > > There is _nothing_ stated if this alternative
> bean should a) only be
> > available for this specific bean archive it is defined
> in or if it b) should
> > be available for _all_ bean archives.
> > >
> > > Imo a) would make absolutely no sense, so it
> clearly is b). This is imo
> > also what weld is doing. But for some weird reason
> Gavin is arguing in
> > exactly the opposite when it comes to interceptors -
> despite the wording in
> > the spec is exactly the same there...
> > >
> >
> > In the modularity section:
> >
> > An alternative is not available for injection, lookup
> or EL resolution
> > to classes or JSP/JSF pages in a module unless the
> module is a bean
> > archive
> > ___and the alternative is explicitly selected in that
> bean archive____
> >
> >
> > There is IMO an option C that is a pretty reasonable
> behavior
> >
> > Assume a WAR with three bean archives.
> >
> > bda1.jar contains a bean that also has an
> alternative.
> > bda2.jar has no enabled alternatives
> > bda3.jar has the alternative enabled.
> >
> > Injection into beans from bda2 behave differently than
> injections into
> > beans from bda2.
> >
> > The biggest confusion for me here is the way that 299
> tries to define
> > a WAR + beans.xml as something different than just a
> BDA in section 5,
> > without going so far as to actually saying it really
> is intended to
> > behave differently (relative to BDA's "inside" of
> it).
> >
> >
> > --
> > Eric Covener
> > covener@gmail.com
> >
> >
> >
>
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
oki, take it one step further.
What would happen if your WAR files do NOT contain those jars, but they are part of the EAR and shared between ALL WARs?
Then (according to the definition in the spec) those JARs are _not_ part of the WARs BDA, isn't?
And thus the interceptors, alternatives and all this stuff simply WONT WORK?
LieGrue,
strub
--- On Mon, 6/21/10, Joseph Bergmark <be...@apache.org> wrote:
> From: Joseph Bergmark <be...@apache.org>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 3:00 PM
> I'm not entirely sure I agree that
> BDAs are only centered around EE
> classloader rules. For example in section 12.1 where
> it talks about
> deployment rules:
>
> "
> In an application deployed as a war, the container searches
> every bean
> deployment archive bundled with or referenced
> by the war. The bean deployment archives might be library
> jars or the
> WEB-INF/classes directory.
> "
>
> This is a simple war case, but the spec talks about
> searching "every" bda
> and "bean deployment archives". I interpret "library
> jars" here to mean jar
> files in the lib directory of the war, which in OWB we
> treat as part of one
> big "bda" including the war itself.
>
> As far as Mark's point about the TCK, I think there may be
> holes in the
> TCK. For example we passed the Decorator tests before
> we ever had support
> for Abstract Decorators, despite that being pretty clearly
> declared as an
> option in section 8.1.3.
>
> Would you be against investigating code that keeps track of
> which BDAs (in
> the war case I mean jars or WEB-INF/classes directories)
> beans were found
> in, and then using that information during
> interceptor/decorator/alternative
> resolution? If nothing else it might segue nicely
> into WAR + EJB scenarios
> later.
>
> Sincerely,
>
> Joe
>
> On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <gu...@yahoo.com>wrote:
>
> > Hello,
> >
> > Currently OWB has not implemented the BDA related
> semantic. BDAs are
> > related with the Java EE classloader rules. For
> example, if you have a EAR
> > file with EJB and WAR, then EAR will have bean
> deployment archive that
> > contains two other BDAs.
> >
> > EAR BDA --> WAR BDA + EJB BDA
> >
> > But EJB BDA does not see the WAR BDA archive. But both
> of them see the
> > common BDA that is located in anywhere in the
> Application Server ClassPath,
> > META-INF/Mainifest.MF ClassPath etc.
> >
> > In summary, BDA is written to work with current Java
> EE classloader
> > semantics. You can look at Java EE specification
> version 6 section "EE 8.3
> > ClasLoading Requirements" to get how classloader
> works.
> >
> >
> > Currently OWB does not support BDAs. Because we
> do not integrate the OWB
> > with full profie Java EE server.
> >
> > This is an one area that OWB needs contribution.
> >
> > I hope this clears the discussion;
> >
> > --Gurkan
> >
> >
> >
> >
> > ________________________________
> > From: Eric Covener <co...@gmail.com>
> > To: dev@openwebbeans.apache.org
> > Sent: Mon, June 21, 2010 3:45:02 PM
> > Subject: Re: problems with lack of archive-centric
> BeanManager
> >
> > On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> > > you picked a good example:
> > >
> > >> | 2.6. Alternatives
> > >> | An alternative is a bean that must be
> explicitly declared
> > >> in the
> > >> beans.xml file if it should be available for
> lookup,
> > >> injection or EL resolution.
> > >
> > > There is _nothing_ stated if this alternative
> bean should a) only be
> > available for this specific bean archive it is defined
> in or if it b) should
> > be available for _all_ bean archives.
> > >
> > > Imo a) would make absolutely no sense, so it
> clearly is b). This is imo
> > also what weld is doing. But for some weird reason
> Gavin is arguing in
> > exactly the opposite when it comes to interceptors -
> despite the wording in
> > the spec is exactly the same there...
> > >
> >
> > In the modularity section:
> >
> > An alternative is not available for injection, lookup
> or EL resolution
> > to classes or JSP/JSF pages in a module unless the
> module is a bean
> > archive
> > ___and the alternative is explicitly selected in that
> bean archive____
> >
> >
> > There is IMO an option C that is a pretty reasonable
> behavior
> >
> > Assume a WAR with three bean archives.
> >
> > bda1.jar contains a bean that also has an
> alternative.
> > bda2.jar has no enabled alternatives
> > bda3.jar has the alternative enabled.
> >
> > Injection into beans from bda2 behave differently than
> injections into
> > beans from bda2.
> >
> > The biggest confusion for me here is the way that 299
> tries to define
> > a WAR + beans.xml as something different than just a
> BDA in section 5,
> > without going so far as to actually saying it really
> is intended to
> > behave differently (relative to BDA's "inside" of
> it).
> >
> >
> > --
> > Eric Covener
> > covener@gmail.com
> >
> >
> >
>
Re: problems with lack of archive-centric BeanManager
Posted by Joseph Bergmark <be...@apache.org>.
I'm not entirely sure I agree that BDAs are only centered around EE
classloader rules. For example in section 12.1 where it talks about
deployment rules:
"
In an application deployed as a war, the container searches every bean
deployment archive bundled with or referenced
by the war. The bean deployment archives might be library jars or the
WEB-INF/classes directory.
"
This is a simple war case, but the spec talks about searching "every" bda
and "bean deployment archives". I interpret "library jars" here to mean jar
files in the lib directory of the war, which in OWB we treat as part of one
big "bda" including the war itself.
As far as Mark's point about the TCK, I think there may be holes in the
TCK. For example we passed the Decorator tests before we ever had support
for Abstract Decorators, despite that being pretty clearly declared as an
option in section 8.1.3.
Would you be against investigating code that keeps track of which BDAs (in
the war case I mean jars or WEB-INF/classes directories) beans were found
in, and then using that information during interceptor/decorator/alternative
resolution? If nothing else it might segue nicely into WAR + EJB scenarios
later.
Sincerely,
Joe
On Mon, Jun 21, 2010 at 8:59 AM, Gurkan Erdogdu <gu...@yahoo.com>wrote:
> Hello,
>
> Currently OWB has not implemented the BDA related semantic. BDAs are
> related with the Java EE classloader rules. For example, if you have a EAR
> file with EJB and WAR, then EAR will have bean deployment archive that
> contains two other BDAs.
>
> EAR BDA --> WAR BDA + EJB BDA
>
> But EJB BDA does not see the WAR BDA archive. But both of them see the
> common BDA that is located in anywhere in the Application Server ClassPath,
> META-INF/Mainifest.MF ClassPath etc.
>
> In summary, BDA is written to work with current Java EE classloader
> semantics. You can look at Java EE specification version 6 section "EE 8.3
> ClasLoading Requirements" to get how classloader works.
>
>
> Currently OWB does not support BDAs. Because we do not integrate the OWB
> with full profie Java EE server.
>
> This is an one area that OWB needs contribution.
>
> I hope this clears the discussion;
>
> --Gurkan
>
>
>
>
> ________________________________
> From: Eric Covener <co...@gmail.com>
> To: dev@openwebbeans.apache.org
> Sent: Mon, June 21, 2010 3:45:02 PM
> Subject: Re: problems with lack of archive-centric BeanManager
>
> On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <st...@yahoo.de> wrote:
> > you picked a good example:
> >
> >> | 2.6. Alternatives
> >> | An alternative is a bean that must be explicitly declared
> >> in the
> >> beans.xml file if it should be available for lookup,
> >> injection or EL resolution.
> >
> > There is _nothing_ stated if this alternative bean should a) only be
> available for this specific bean archive it is defined in or if it b) should
> be available for _all_ bean archives.
> >
> > Imo a) would make absolutely no sense, so it clearly is b). This is imo
> also what weld is doing. But for some weird reason Gavin is arguing in
> exactly the opposite when it comes to interceptors - despite the wording in
> the spec is exactly the same there...
> >
>
> In the modularity section:
>
> An alternative is not available for injection, lookup or EL resolution
> to classes or JSP/JSF pages in a module unless the module is a bean
> archive
> ___and the alternative is explicitly selected in that bean archive____
>
>
> There is IMO an option C that is a pretty reasonable behavior
>
> Assume a WAR with three bean archives.
>
> bda1.jar contains a bean that also has an alternative.
> bda2.jar has no enabled alternatives
> bda3.jar has the alternative enabled.
>
> Injection into beans from bda2 behave differently than injections into
> beans from bda2.
>
> The biggest confusion for me here is the way that 299 tries to define
> a WAR + beans.xml as something different than just a BDA in section 5,
> without going so far as to actually saying it really is intended to
> behave differently (relative to BDA's "inside" of it).
>
>
> --
> Eric Covener
> covener@gmail.com
>
>
>
Re: problems with lack of archive-centric BeanManager
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
Hello,
Currently OWB has not implemented the BDA related semantic. BDAs are related with the Java EE classloader rules. For example, if you have a EAR file with EJB and WAR, then EAR will have bean deployment archive that contains two other BDAs.
EAR BDA --> WAR BDA + EJB BDA
But EJB BDA does not see the WAR BDA archive. But both of them see the common BDA that is located in anywhere in the Application Server ClassPath, META-INF/Mainifest.MF ClassPath etc.
In summary, BDA is written to work with current Java EE classloader semantics. You can look at Java EE specification version 6 section "EE 8.3 ClasLoading Requirements" to get how classloader works.
Currently OWB does not support BDAs. Because we do not integrate the OWB with full profie Java EE server.
This is an one area that OWB needs contribution.
I hope this clears the discussion;
--Gurkan
________________________________
From: Eric Covener <co...@gmail.com>
To: dev@openwebbeans.apache.org
Sent: Mon, June 21, 2010 3:45:02 PM
Subject: Re: problems with lack of archive-centric BeanManager
On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <st...@yahoo.de> wrote:
> you picked a good example:
>
>> | 2.6. Alternatives
>> | An alternative is a bean that must be explicitly declared
>> in the
>> beans.xml file if it should be available for lookup,
>> injection or EL resolution.
>
> There is _nothing_ stated if this alternative bean should a) only be available for this specific bean archive it is defined in or if it b) should be available for _all_ bean archives.
>
> Imo a) would make absolutely no sense, so it clearly is b). This is imo also what weld is doing. But for some weird reason Gavin is arguing in exactly the opposite when it comes to interceptors - despite the wording in the spec is exactly the same there...
>
In the modularity section:
An alternative is not available for injection, lookup or EL resolution
to classes or JSP/JSF pages in a module unless the module is a bean
archive
___and the alternative is explicitly selected in that bean archive____
There is IMO an option C that is a pretty reasonable behavior
Assume a WAR with three bean archives.
bda1.jar contains a bean that also has an alternative.
bda2.jar has no enabled alternatives
bda3.jar has the alternative enabled.
Injection into beans from bda2 behave differently than injections into
beans from bda2.
The biggest confusion for me here is the way that 299 tries to define
a WAR + beans.xml as something different than just a BDA in section 5,
without going so far as to actually saying it really is intended to
behave differently (relative to BDA's "inside" of it).
--
Eric Covener
covener@gmail.com
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
Umm, but how would you then 'switch' a Service which is defined in a jar you only use (for example a common utilities jar in your company) to behave different in your project? For what I understand
mycomp-utils.jar <- contains MailServiceImpl.java
is being used by
mycomp-myprj.jar <- contains MyAlternativeMailServiceImpl.java
Then there is no way (other than to modify mycomp-utils.jar) to switch to the alternate mail service for classes defined in mycomp-utils.jar?
Either I'm getting this wrong, or this is _completely_ bullsh**ish...
LieGrue,
strub
--- On Mon, 6/21/10, Eric Covener <co...@gmail.com> wrote:
> From: Eric Covener <co...@gmail.com>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 12:45 PM
> On Mon, Jun 21, 2010 at 7:53 AM, Mark
> Struberg <st...@yahoo.de>
> wrote:
> > you picked a good example:
> >
> >> | 2.6. Alternatives
> >> | An alternative is a bean that must be explicitly
> declared
> >> in the
> >> beans.xml file if it should be available for
> lookup,
> >> injection or EL resolution.
> >
> > There is _nothing_ stated if this alternative bean
> should a) only be available for this specific bean archive
> it is defined in or if it b) should be available for _all_
> bean archives.
> >
> > Imo a) would make absolutely no sense, so it clearly
> is b). This is imo also what weld is doing. But for some
> weird reason Gavin is arguing in exactly the opposite when
> it comes to interceptors - despite the wording in the spec
> is exactly the same there...
> >
>
> In the modularity section:
>
> An alternative is not available for injection, lookup or EL
> resolution
> to classes or JSP/JSF pages in a module unless the module
> is a bean
> archive
> ___and the alternative is explicitly selected in that bean
> archive____
>
>
> There is IMO an option C that is a pretty reasonable
> behavior
>
> Assume a WAR with three bean archives.
>
> bda1.jar contains a bean that also has an alternative.
> bda2.jar has no enabled alternatives
> bda3.jar has the alternative enabled.
>
> Injection into beans from bda2 behave differently than
> injections into
> beans from bda2.
>
> The biggest confusion for me here is the way that 299 tries
> to define
> a WAR + beans.xml as something different than just a BDA in
> section 5,
> without going so far as to actually saying it really is
> intended to
> behave differently (relative to BDA's "inside" of it).
>
>
> --
> Eric Covener
> covener@gmail.com
>
Re: problems with lack of archive-centric BeanManager
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jun 21, 2010 at 7:53 AM, Mark Struberg <st...@yahoo.de> wrote:
> you picked a good example:
>
>> | 2.6. Alternatives
>> | An alternative is a bean that must be explicitly declared
>> in the
>> beans.xml file if it should be available for lookup,
>> injection or EL resolution.
>
> There is _nothing_ stated if this alternative bean should a) only be available for this specific bean archive it is defined in or if it b) should be available for _all_ bean archives.
>
> Imo a) would make absolutely no sense, so it clearly is b). This is imo also what weld is doing. But for some weird reason Gavin is arguing in exactly the opposite when it comes to interceptors - despite the wording in the spec is exactly the same there...
>
In the modularity section:
An alternative is not available for injection, lookup or EL resolution
to classes or JSP/JSF pages in a module unless the module is a bean
archive
___and the alternative is explicitly selected in that bean archive____
There is IMO an option C that is a pretty reasonable behavior
Assume a WAR with three bean archives.
bda1.jar contains a bean that also has an alternative.
bda2.jar has no enabled alternatives
bda3.jar has the alternative enabled.
Injection into beans from bda2 behave differently than injections into
beans from bda2.
The biggest confusion for me here is the way that 299 tries to define
a WAR + beans.xml as something different than just a BDA in section 5,
without going so far as to actually saying it really is intended to
behave differently (relative to BDA's "inside" of it).
--
Eric Covener
covener@gmail.com
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
you picked a good example:
> | 2.6. Alternatives
> | An alternative is a bean that must be explicitly declared
> in the
> beans.xml file if it should be available for lookup,
> injection or EL resolution.
There is _nothing_ stated if this alternative bean should a) only be available for this specific bean archive it is defined in or if it b) should be available for _all_ bean archives.
Imo a) would make absolutely no sense, so it clearly is b). This is imo also what weld is doing. But for some weird reason Gavin is arguing in exactly the opposite when it comes to interceptors - despite the wording in the spec is exactly the same there...
LieGrue,
strub
--- On Mon, 6/21/10, Eric Covener <co...@gmail.com> wrote:
> From: Eric Covener <co...@gmail.com>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Monday, June 21, 2010, 11:34 AM
> On Mon, Jun 21, 2010 at 5:41 AM, Mark
> Struberg <st...@yahoo.de>
> wrote:
> > If you can point me to the paragraph in the spec and
> the corresponding TCK test where it is clearly stated that
> an interceptor enablement is only meant to work for the
> current bean archive bundle, then please provide it.
>
> I don't know about the TCK, but clearly all the elements of
> the
> beans.xml are BDA-centric.
>
>
> | 2.6. Alternatives
> | An alternative is a bean that must be explicitly declared
> in the
> beans.xml file if it should be available for lookup,
> injection or EL
> resolution.
>
>
> | 9.4. Interceptor enablement and ordering
> | By default, a bean archive has no enabled interceptors
> bound via
> interceptor bindings. An interceptor must be explicitly
> enabled by
> listing its class under the <interceptors> element of
> the beans.xml
> file of the bean archive.
>
>
> You can't have interceptors enabled (and ordered) anywhere
> else,
> unless you manufacture a notion of a hierarchy of BDA's, in
> which case
> we need the very same change to reflect that
> relation. I'm not even
> considering the idea that the BDA of the interceptor class
> itself is
> where it ought to be enabled for all other beans, as this
> vicarious
> enablement would be totally off the charts.
>
>
> --
> Eric Covener
> covener@gmail.com
>
Re: problems with lack of archive-centric BeanManager
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jun 21, 2010 at 5:41 AM, Mark Struberg <st...@yahoo.de> wrote:
> If you can point me to the paragraph in the spec and the corresponding TCK test where it is clearly stated that an interceptor enablement is only meant to work for the current bean archive bundle, then please provide it.
I don't know about the TCK, but clearly all the elements of the
beans.xml are BDA-centric.
| 2.6. Alternatives
| An alternative is a bean that must be explicitly declared in the
beans.xml file if it should be available for lookup, injection or EL
resolution.
| 9.4. Interceptor enablement and ordering
| By default, a bean archive has no enabled interceptors bound via
interceptor bindings. An interceptor must be explicitly enabled by
listing its class under the <interceptors> element of the beans.xml
file of the bean archive.
You can't have interceptors enabled (and ordered) anywhere else,
unless you manufacture a notion of a hierarchy of BDA's, in which case
we need the very same change to reflect that relation. I'm not even
considering the idea that the BDA of the interceptor class itself is
where it ought to be enabled for all other beans, as this vicarious
enablement would be totally off the charts.
--
Eric Covener
covener@gmail.com
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
If you can point me to the paragraph in the spec and the corresponding TCK test where it is clearly stated that an interceptor enablement is only meant to work for the current bean archive bundle, then please provide it.
Interceptor enabling rules are a mess in the spec and the long discussions you can find on the weld-dev list imo shows this clearly.
LieGrue,
strub
--- On Sun, 6/20/10, Eric Covener <co...@gmail.com> wrote:
> From: Eric Covener <co...@gmail.com>
> Subject: Re: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Sunday, June 20, 2010, 10:23 PM
> On Tue, Jun 15, 2010 at 6:46 AM, Mark
> Struberg <st...@yahoo.de>
> wrote:
> > I had a long discussion about that and the spec is imo
> ambigous.
> >
> > Currently our implementation does not behave the same
> way as weld, but we clearly fulfil the spec. I've wrote this
> to Gavin but got no answer since.
>
> I don't think we fulfill the spec with regards to enabling
> interceptors and decorators (and probably alternatives) on
> a
> BDA-by-BDA basis.
>
> --
> Eric Covener
> covener@gmail.com
>
Re: problems with lack of archive-centric BeanManager
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jun 15, 2010 at 6:46 AM, Mark Struberg <st...@yahoo.de> wrote:
> I had a long discussion about that and the spec is imo ambigous.
>
> Currently our implementation does not behave the same way as weld, but we clearly fulfil the spec. I've wrote this to Gavin but got no answer since.
I don't think we fulfill the spec with regards to enabling
interceptors and decorators (and probably alternatives) on a
BDA-by-BDA basis.
--
Eric Covener
covener@gmail.com
Re: problems with lack of archive-centric BeanManager
Posted by Mark Struberg <st...@yahoo.de>.
I had a long discussion about that and the spec is imo ambigous.
Currently our implementation does not behave the same way as weld, but we clearly fulfil the spec. I've wrote this to Gavin but got no answer since.
LieGrue,
strub
--- On Tue, 6/15/10, Eric Covener <co...@gmail.com> wrote:
> From: Eric Covener <co...@gmail.com>
> Subject: problems with lack of archive-centric BeanManager
> To: dev@openwebbeans.apache.org
> Date: Tuesday, June 15, 2010, 10:21 AM
> Currently the OWB BeanManager does
> not retain much info about
> individual Archives (whether they be BDA's or non-BDA's),
> only the
> aggregate classes and beanXML's.
>
> For the sake of discussion, consider a WAR with three
> utility jar's in
> the lib/ directory.
>
> a.jar is a BDA that defines an
> interceptor binding and an interceptor
> b.jar is a BDA that defines a managed
> bean with the aforementioned
> InterceptorBinding
> c.jar is a BDA that defines a managed
> bean with the aforementioned
> InterceptorBinding.
>
> Our current design does not permit either of the following
> scenarions, AFAICT:
>
> b.jar and c.jar both enable the interceptor defined
> in a.jar
> (treated as a duplicate)
> Exactly one of b.jar and c.jar enables the
> interceptor defined in
> a.jar (ends up enabled for beans from either archive if
> enabled in one
> -- this is in the more troubling neighborhood)
>
> This is primarily because between the BeanManager and the
> ScannerService, we lose all granularity abut the source of
> classes and
> beanXML's. This manifests itself in slightly more
> involved ways, such
> as when an applications contains multiple modules with
> multiple
> classloaders. Neither 1 BeanManager or N BeanManagers
> seems too
> appealing in this case.
>
> There has been some offline discussion about:
>
> * introduce a first-class data structure to
> represent a Archive
> (composed of classes, XML's, and Archive references)
> * teach the ScannService or some successor to return
> lists of
> Archives to the deployment code
> * teach the BeanManager to manage a network of
> Archives to properly
> follow the EE accessibility rules
>
> I took a crack at illustrating this on top of guess by
> adding separate
> sub-modules for the utility jars as described above
>
> http://people.apache.org/~covener/owb/
>
> OOTB this results in a disabled (for a specific bean based
> on the BDA
> it comes from ) interceptor being run.
>
>
> --
> Eric Covener
> covener@gmail.com
>