<div dir="ltr">>In this particular case it concerns the javax.faces.jar for JSF 2.3.<br>>Some vendors split up this archive in two, an API jar and an impl, jar<br>>(although for JSF 2.3 we don't really encourage this).<br><div class="gmail_extra"><br></div><div class="gmail_extra">Could you explain, why the JSF 2.3 API and RI are molded together?</div><div class="gmail_extra">If the API JAR is no longer separate from the RI (as it was till <a href="http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar" target="_blank" style="margin:0px;color:rgb(0,51,102);font-family:arial,helvetica,'sans serif';font-size:12px;line-height:22px">javax.faces-api-2.2.jar</a>) 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 ?;-|</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;font-size:13px;border-collapse:collapse"><span lang="EN-US" style="font-family:Calibri">Werner</span></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 12, 2015 at 11:07 AM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. getBeanClass return value for build-in beans? (arjan tijms)<br>
2. CDI 2.0 EDR: Questions on asynchronous observers (Nigel Deakin)<br>
3. Re: getBeanClass return value for build-in beans?<br>
(Jozef Hartinger)<br>
4. Re: getBeanClass return value for build-in beans? (Martin Kouba)<br>
5. Re: CDI 2.0 EDR: Questions on asynchronous observers<br>
(Jozef Hartinger)<br>
6. Re: getBeanClass return value for build-in beans? (arjan tijms)<br>
7. Re: getBeanClass return value for build-in beans? (arjan tijms)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>Message: 6<br>
Date: Wed, 12 Aug 2015 11:07:04 +0200<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?<br>
To: Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>><br>
Cc: "<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=<a href="mailto:g@mail.gmail.com">g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>> wrote:<br>
> Therefore, you are free to use any class as a bean class that:<br>
> 1) properly identifies the bean archive (i.e. is located in the bean archive<br>
> where you want the custom bean to belong)<br>
<br>
In this particular case it concerns the javax.faces.jar for JSF 2.3.<br>
Some vendors split up this archive in two, an API jar and an impl, jar<br>
(although for JSF 2.3 we don't really encourage this). Therefor it<br>
looks like it does make a difference if the Bean<T> implementation<br>
will return this.class (an implementation type, like Weld does) or say<br>
Flash.class (an API class).<br>
<br>
> What you indicated in the previous e-mails - that Weld does not work<br>
> properly if the bean class is an abstract class looks like a bug in Weld<br>
> that I will be investigating.<br>
<br>
I'm not 100% sure what the intend is. Is the proxy supposed to only<br>
implement methods of the Types that are returned by the Bean<T><br>
implementation, or should it be smart enough to look at the super<br>
types of whatever Type is returned?<br>
<br>
So given:<br>
<br>
public abstract class AbstractClass implements Interface { ... }<br>
<br>
If getTypes returns only Abstract.class, then only the methods defined<br>
by AbstractClass itself are implemented by the proxy. Those from<br>
Interface throw exceptions when called.<br>
<br>
If getTypes returns both Abstract.class and Interface.class, then all<br>
methods defined by AbstractClass and Interface are implemented by the<br>
proxy.<br>
<br>
Is this how things should be, or should the proxy generator see for<br>
itself that AbstractClass implements Interface?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
><br>
> HTH,<br>
><br>
> Jozef<br>
><br>
><br>
><br>
><br>
> On 11.8.2015 12:26, arjan tijms wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> This is split-off from the thread "Bean<T> that only qualifies super<br>
>> types?", where the question came up what a Bean<T> should return from<br>
>> the getBeanClass() method for the case of build-in beans.<br>
>><br>
>> The JavaDoc for getBeanClass() currently says the following:<br>
>><br>
>> "The bean class of the managed bean or session bean or of the bean<br>
>> that declares the producer method or field."<br>
>><br>
>> See:<br>
>> <a href="https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()" rel="noreferrer" target="_blank">https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()</a><br>
>><br>
>> The case where a Bean<T> instance is directly created and added as<br>
>> bean to AfterBeanDiscovery in an extension does not seem to be covered<br>
>> by this documentation.<br>
>><br>
>> Weld returns "this.class" here.<br>
>><br>
>> See<br>
>> <a href="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" rel="noreferrer" target="_blank">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</a><br>
>><br>
>> Is that what build-in beans should always do, and if so, should the<br>
>> JavaDoc/spec be clarified for this?<br>
>><br>
>> Kind regards,<br>
>> Arjan Tijms<br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other intellectual<br>
>> property rights inherent in such information.<br>
>><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 12 Aug 2015 11:07:51 +0200<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?<br>
To: Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
Cc: "<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-AhDy_B+mt4kPJqVtP+FAyFEJdzMGC7AS2Qga7=<a href="mailto:q3iVwmcA@mail.gmail.com">q3iVwmcA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Martin,<br>
<br>
On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> wrote:<br>
> please create a new spec issue. This should be definitely clarified.<br>
<br>
I'll do that, thanks!<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
><br>
> Thanks,<br>
> Martin<br>
><br>
> Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):<br>
><br>
>> Hi Arjan,<br>
>><br>
>> the bean class in CDI is used for two purposes:<br>
>><br>
>> 1) to identify the bean archive the bean belongs to (this is crucial for<br>
>> inter-module injection)<br>
>> 2) if the bean is an alternative, interceptor or decorator the bean<br>
>> class is used for matching with beans.xml enablement entries<br>
>><br>
>> Other than these, there are no restrictions imposed by the spec. Note<br>
>> that there is absolutely no requirement that the bean class is part of<br>
>> the bean types (as demonstrated by producer method/fields for example).<br>
>><br>
>> Therefore, you are free to use any class as a bean class that:<br>
>> 1) properly identifies the bean archive (i.e. is located in the bean<br>
>> archive where you want the custom bean to belong)<br>
>> 2) if the bean is an alternative, interceptor or decorator then choose<br>
>> the class whose name you want people to put to beans.xml when enabling it<br>
>><br>
>> What you indicated in the previous e-mails - that Weld does not work<br>
>> properly if the bean class is an abstract class looks like a bug in Weld<br>
>> that I will be investigating.<br>
>><br>
>> HTH,<br>
>><br>
>> Jozef<br>
>><br>
>><br>
>><br>
>> On 11.8.2015 12:26, arjan tijms wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> This is split-off from the thread "Bean<T> that only qualifies super<br>
>>> types?", where the question came up what a Bean<T> should return from<br>
>>> the getBeanClass() method for the case of build-in beans.<br>
>>><br>
>>> The JavaDoc for getBeanClass() currently says the following:<br>
>>><br>
>>> "The bean class of the managed bean or session bean or of the bean<br>
>>> that declares the producer method or field."<br>
>>><br>
>>> See:<br>
>>> <a href="https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()" rel="noreferrer" target="_blank">https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()</a><br>
>>><br>
>>> The case where a Bean<T> instance is directly created and added as<br>
>>> bean to AfterBeanDiscovery in an extension does not seem to be covered<br>
>>> by this documentation.<br>
>>><br>
>>> Weld returns "this.class" here.<br>
>>><br>
>>> See<br>
>>> <a href="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" rel="noreferrer" target="_blank">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</a><br>
>>><br>
>>> Is that what build-in beans should always do, and if so, should the<br>
>>> JavaDoc/spec be clarified for this?<br>
>>><br>
>>> Kind regards,<br>
>>> Arjan Tijms<br>
>>> _______________________________________________<br>
>>> cdi-dev mailing list<br>
>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>><br>
>>> Note that for all code provided on this list, the provider licenses the<br>
>>> code under the Apache License, Version 2<br>
>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>> provided on this list, the provider waives all patent and other intellectual<br>
>>> property rights inherent in such information.<br>
>>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other intellectual<br>
>> property rights inherent in such information.<br>
>><br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 57, Issue 6<br>
**************************************<br>
</blockquote></div><br></div></div>