[cdi-dev] getBeanClass return value for build-in beans?
Werner Keil
werner.keil at gmail.com
Thu Aug 13 09:24:00 EDT 2015
>In this particular case it concerns the javax.faces.jar for JSF 2.3.
>Some vendors split up this archive in two, an API jar and an impl, jar
>(although for JSF 2.3 we don't really encourage this).
Could you explain, why the JSF 2.3 API and RI are molded together?
If the API JAR is no longer separate from the RI (as it was till
javax.faces-api-2.2.jar
<http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar>)
it seems, every vendor has to build that API JAR from scratch, or carry a
3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
Not to mention often bizarre side-effects if you (accidentially in that
case) mix multiple JSF implementations in some web-apps. I had to resolve
many of those myself between e.g. the JBoss implementation and Apache
RichFaces.
Werner
On Wed, Aug 12, 2015 at 11:07 AM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. getBeanClass return value for build-in beans? (arjan tijms)
> 2. CDI 2.0 EDR: Questions on asynchronous observers (Nigel Deakin)
> 3. Re: getBeanClass return value for build-in beans?
> (Jozef Hartinger)
> 4. Re: getBeanClass return value for build-in beans? (Martin Kouba)
> 5. Re: CDI 2.0 EDR: Questions on asynchronous observers
> (Jozef Hartinger)
> 6. Re: getBeanClass return value for build-in beans? (arjan tijms)
> 7. Re: getBeanClass return value for build-in beans? (arjan tijms)
>
>
> ----------------------------------------------------------------------
>
> Message: 6
> Date: Wed, 12 Aug 2015 11:07:04 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Jozef Hartinger <jharting at redhat.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=
> g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> > Therefore, you are free to use any class as a bean class that:
> > 1) properly identifies the bean archive (i.e. is located in the bean
> archive
> > where you want the custom bean to belong)
>
> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> Some vendors split up this archive in two, an API jar and an impl, jar
> (although for JSF 2.3 we don't really encourage this). Therefor it
> looks like it does make a difference if the Bean<T> implementation
> will return this.class (an implementation type, like Weld does) or say
> Flash.class (an API class).
>
> > What you indicated in the previous e-mails - that Weld does not work
> > properly if the bean class is an abstract class looks like a bug in Weld
> > that I will be investigating.
>
> I'm not 100% sure what the intend is. Is the proxy supposed to only
> implement methods of the Types that are returned by the Bean<T>
> implementation, or should it be smart enough to look at the super
> types of whatever Type is returned?
>
> So given:
>
> public abstract class AbstractClass implements Interface { ... }
>
> If getTypes returns only Abstract.class, then only the methods defined
> by AbstractClass itself are implemented by the proxy. Those from
> Interface throw exceptions when called.
>
> If getTypes returns both Abstract.class and Interface.class, then all
> methods defined by AbstractClass and Interface are implemented by the
> proxy.
>
> Is this how things should be, or should the proxy generator see for
> itself that AbstractClass implements Interface?
>
> Kind regards,
> Arjan Tijms
>
>
> >
> > HTH,
> >
> > Jozef
> >
> >
> >
> >
> > On 11.8.2015 12:26, arjan tijms wrote:
> >>
> >> Hi,
> >>
> >> This is split-off from the thread "Bean<T> that only qualifies super
> >> types?", where the question came up what a Bean<T> should return from
> >> the getBeanClass() method for the case of build-in beans.
> >>
> >> The JavaDoc for getBeanClass() currently says the following:
> >>
> >> "The bean class of the managed bean or session bean or of the bean
> >> that declares the producer method or field."
> >>
> >> See:
> >>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
> >>
> >> The case where a Bean<T> instance is directly created and added as
> >> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >> by this documentation.
> >>
> >> Weld returns "this.class" here.
> >>
> >> See
> >>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
> >>
> >> Is that what build-in beans should always do, and if so, should the
> >> JavaDoc/spec be clarified for this?
> >>
> >> Kind regards,
> >> Arjan Tijms
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> intellectual
> >> property rights inherent in such information.
> >>
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 12 Aug 2015 11:07:51 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Martin Kouba <mkouba at redhat.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-AhDy_B+mt4kPJqVtP+FAyFEJdzMGC7AS2Qga7=
> q3iVwmcA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Martin,
>
> On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <mkouba at redhat.com> wrote:
> > please create a new spec issue. This should be definitely clarified.
>
> I'll do that, thanks!
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Thanks,
> > Martin
> >
> > Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
> >
> >> Hi Arjan,
> >>
> >> the bean class in CDI is used for two purposes:
> >>
> >> 1) to identify the bean archive the bean belongs to (this is crucial for
> >> inter-module injection)
> >> 2) if the bean is an alternative, interceptor or decorator the bean
> >> class is used for matching with beans.xml enablement entries
> >>
> >> Other than these, there are no restrictions imposed by the spec. Note
> >> that there is absolutely no requirement that the bean class is part of
> >> the bean types (as demonstrated by producer method/fields for example).
> >>
> >> Therefore, you are free to use any class as a bean class that:
> >> 1) properly identifies the bean archive (i.e. is located in the bean
> >> archive where you want the custom bean to belong)
> >> 2) if the bean is an alternative, interceptor or decorator then choose
> >> the class whose name you want people to put to beans.xml when enabling
> it
> >>
> >> What you indicated in the previous e-mails - that Weld does not work
> >> properly if the bean class is an abstract class looks like a bug in Weld
> >> that I will be investigating.
> >>
> >> HTH,
> >>
> >> Jozef
> >>
> >>
> >>
> >> On 11.8.2015 12:26, arjan tijms wrote:
> >>>
> >>> Hi,
> >>>
> >>> This is split-off from the thread "Bean<T> that only qualifies super
> >>> types?", where the question came up what a Bean<T> should return from
> >>> the getBeanClass() method for the case of build-in beans.
> >>>
> >>> The JavaDoc for getBeanClass() currently says the following:
> >>>
> >>> "The bean class of the managed bean or session bean or of the bean
> >>> that declares the producer method or field."
> >>>
> >>> See:
> >>>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
> >>>
> >>> The case where a Bean<T> instance is directly created and added as
> >>> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >>> by this documentation.
> >>>
> >>> Weld returns "this.class" here.
> >>>
> >>> See
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
> >>>
> >>> Is that what build-in beans should always do, and if so, should the
> >>> JavaDoc/spec be clarified for this?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses the
> >>> code under the Apache License, Version 2
> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >>> provided on this list, the provider waives all patent and other
> intellectual
> >>> property rights inherent in such information.
> >>>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> intellectual
> >> property rights inherent in such information.
> >>
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 57, Issue 6
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/1e7244f7/attachment-0001.html
More information about the cdi-dev
mailing list