<div dir="ltr">Btw. I think some aspects of this thread seem a little off-topic or more specific to the JSR 375 list instead (or at least it would be good to CC that one for detailed java.security discussions rather than if a generic type works or not)<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;border-collapse:collapse"><font face="arial, helvetica, sans-serif" size="1"><span lang="EN-US">Werner</span></font></p><span lang="EN-GB"><div style="font-family:arial,helvetica,sans-serif"><br></div></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 26, 2017 at 6:11 PM, <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/<wbr>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.<wbr>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. Re: Types of Principal object (arjan tijms)<br>
2. Re: Types of Principal object (arjan tijms)<br>
3. Re: Types of Principal object (Romain Manni-Bucau)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 26 Apr 2017 18:00:40 +0200<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Subject: Re: [cdi-dev] Types of Principal object<br>
To: Matej Novotny <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-AhBp8cLUxWOpnT=<a href="mailto:oyp-h%2Bf2uYDgUvwJDfSkzYjRqha5HHA@mail.gmail.com">oyp-h+<wbr>f2uYDgUvwJDfSkzYjRqha5HHA@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>> wrote:<br>
<br>
> And spec requires all built-in beans to be decorable - e.g. you need them<br>
> to be proxyable (although the added value of principal decorator is ...eh,<br>
> disputable at best?).<br>
><br>
<br>
That would be kinda disputable indeed :O<br>
<br>
<br>
> Therefore, it is safer/viable to create a proxyable wrapper object which<br>
> implements Principal only and delegetas calls (that's what Weld does).<br>
><br>
<br>
As i mentioned, the proxy has to be there as just injecting a non-proxy<br>
Principal would not work correctly. If a logout call is done, the injected<br>
Principal would still be the principal that it was before, let alone what<br>
happens if the Principal is inject in application scoped beans...<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
><br>
> Otherwise I agree it could be nice to ahve a way to cast the object as the<br>
> pure Principal interface doesn't help much.<br>
><br>
> Matej<br>
><br>
> ----- Original Message -----<br>
> > From: "John Ament" <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a>><br>
> > To: "cdi-dev" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > Sent: Wednesday, April 26, 2017 3:54:57 PM<br>
> > Subject: [cdi-dev] Types of Principal object<br>
> ><br>
> ><br>
> ><br>
> > Hey guys<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > I raised a bug against the Weld guys, but think its worth an EG<br>
> discussion.<br>
> > When a Principal object is injected, the only type it has is Principal.<br>
> It<br>
> > does not retain the actual type used at runtime. This threw me off on<br>
> some<br>
> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is<br>
> > this expected from our POV or should it retain the types of the actual<br>
> > runtime instance?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > John<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > NOTICE: This e-mail message and any attachments may contain confidential,<br>
> > proprietary, and/or privileged information which should be treated<br>
> > accordingly. If you are not the intended recipient, please notify the<br>
> sender<br>
> > immediately by return e-mail, delete this message, and destroy all<br>
> physical<br>
> > and electronic copies. Thank you.<br>
> ><br>
> > ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider licenses the<br>
> code<br>
> > 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/<wbr>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> > provided on this list, the provider waives all patent and other<br>
> intellectual<br>
> > property rights inherent in such information.<br>
> ______________________________<wbr>_________________<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/<wbr>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 (<a href="http://www.apache.org/" rel="noreferrer" target="_blank">http://www.apache.org/</a><br>
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,<br>
> the provider waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1b8d735a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/<wbr>pipermail/cdi-dev/attachments/<wbr>20170426/1b8d735a/attachment-<wbr>0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 26 Apr 2017 18:07:52 +0200<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Subject: Re: [cdi-dev] Types of Principal object<br>
To: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-<a href="mailto:AhC2YBs0biFaRPpxrpiXy4WTaKU_Xsm%2BnxSCk3mUkhZYQg@mail.gmail.com">AhC2YBs0biFaRPpxrpiXy4WT<wbr>aKU_Xsm+nxSCk3mUkhZYQg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
wrote:<br>
<br>
> that's why security API needs a more typed API acting as an handler and<br>
> not as a contextual instance, it would allow to unwrap the actual instance<br>
> (like most specs do)<br>
><br>
<br>
I think that would require a new Principal type, which can be done, but<br>
who's going to put time into it to discuss it, spec it, implement it, etc?<br>
<br>
Also, the difference with the current situation is not that much then.<br>
<br>
Extended Principal:<br>
<br>
<br>
@Inject CallerPrincipal callerPrincipal;<br>
<br>
...<br>
<br>
MyPrincipal myPrincipal = callerPrincipal.unwrap();<br>
<br>
<br>
vs<br>
<br>
<br>
Security context:<br>
<br>
@Inject SecurityContext securityContext;<br>
<br>
...<br>
<br>
MyPrincipal myPrincipal = securityContext.<wbr>getCallerPrincipal();<br>
<br>
Spot the differences ;)<br>
<br>
<br>
<br>
> In other words either Principal is removed from CDI spec<br>
><br>
<br>
I think this should be done anyway. The build-in bean for Principal would<br>
be more at home with the Security API spec. I would be happy to take it in<br>
;)<br>
<br>
(likewise, the build-in bean for HttpServletRequest etc should be with the<br>
Servlet spec)<br>
<br>
<br>
<br>
> or it stays but it should be extended to be made usable IMHO.<br>
><br>
<br>
What CDI could provide and which has been discussed before, is a method to<br>
get the real bean from a proxy. E.g.<br>
<br>
@Inject CallerPrincipal callerPrincipal;<br>
@Inject BeanManager beanManager;<br>
<br>
...<br>
<br>
MyPrincipal myPrincipal = beanManager.unwrap(<wbr>callerPrincipal);<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
><br>
><br>
> Romain Manni-Bucau<br>
> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a>> | Blog<br>
> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a>> | Old Blog<br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.<wbr>com</a>> | Github<br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a>> | LinkedIn<br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a>> | JavaEE Factory<br>
> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a>><br>
><br>
> 2017-04-26 17:11 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
><br>
>> Hi,<br>
>><br>
>> We discussed this very issue in the Security API EG as well. In the<br>
>> Security API the actual type *MUST* be retained as per the spec definition.<br>
>><br>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This<br>
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where<br>
>> AbstractEEBean does:<br>
>><br>
>> public abstract class AbstractEEBean<T> extends<br>
>> AbstractStaticallyDecorableBui<wbr>ltInBean<T> {<br>
>><br>
>> private final T proxy;<br>
>><br>
>> protected AbstractEEBean(Class<T> type, Callable<T> callable,<br>
>> BeanManagerImpl beanManager) {<br>
>> super(beanManager, type);<br>
>> this.proxy = new ProxyFactory<T>(beanManager.<wbr>getContextId(),<br>
>> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(<wbr>type,<br>
>> new CallableMethodHandler(<wbr>callable)));<br>
>> }<br>
>> // ...<br>
>> }<br>
>><br>
>> I'm not even sure if it's possible to downcast the proxy to the required<br>
>> runtime type.<br>
>><br>
>> Also note that the Principal can change during the request. The simplest<br>
>> case is when during an http request HttpServletRequest#logout is called.<br>
>><br>
>> Kind regards,<br>
>> Arjan Tijms<br>
>><br>
>><br>
>><br>
>><br>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a><br>
>> > wrote:<br>
>><br>
>>> Hey guys<br>
>>><br>
>>><br>
>>> I raised a bug against the Weld guys, but think its worth an EG<br>
>>> discussion. When a Principal object is injected, the only type it has is<br>
>>> Principal. It does not retain the actual type used at runtime. This threw<br>
>>> me off on some Keycloak integration I'm working on (in $dayjob). So I was<br>
>>> wondering, is this expected from our POV or should it retain the types of<br>
>>> the actual runtime instance?<br>
>>><br>
>>><br>
>>> John<br>
>>><br>
>>> ------------------------------<br>
>>> NOTICE: This e-mail message and any attachments may contain<br>
>>> confidential, proprietary, and/or privileged information which should be<br>
>>> treated accordingly. If you are not the intended recipient, please notify<br>
>>> the sender immediately by return e-mail, delete this message, and destroy<br>
>>> all physical and electronic copies. Thank you.<br>
>>><br>
>>> ______________________________<wbr>_________________<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/<wbr>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 (<a href="http://www.apache.org/license" rel="noreferrer" target="_blank">http://www.apache.org/license</a><br>
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the<br>
>>> provider waives all patent and other intellectual property rights inherent<br>
>>> in such information.<br>
>>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<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/<wbr>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 (<a href="http://www.apache.org/license" rel="noreferrer" target="_blank">http://www.apache.org/license</a><br>
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the<br>
>> provider waives all patent and other intellectual property rights inherent<br>
>> in such information.<br>
>><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/9cd63650/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/<wbr>pipermail/cdi-dev/attachments/<wbr>20170426/9cd63650/attachment-<wbr>0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 26 Apr 2017 18:10:10 +0200<br>
From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Subject: Re: [cdi-dev] Types of Principal object<br>
To: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=<a href="mailto:7MCs1XrpCnNjSXSM92aXW31kKLdb1EnmER7Z6MTkGnFXw@mail.gmail.com">7MCs1XrpCnNjSXSM92aXW31<wbr>kKLdb1EnmER7Z6MTkGnFXw@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2017-04-26 18:07 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
<br>
> Hi,<br>
><br>
> On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a><br>
> > wrote:<br>
><br>
>> that's why security API needs a more typed API acting as an handler and<br>
>> not as a contextual instance, it would allow to unwrap the actual instance<br>
>> (like most specs do)<br>
>><br>
><br>
> I think that would require a new Principal type, which can be done, but<br>
> who's going to put time into it to discuss it, spec it, implement it, etc?<br>
><br>
> Also, the difference with the current situation is not that much then.<br>
><br>
> Extended Principal:<br>
><br>
><br>
> @Inject CallerPrincipal callerPrincipal;<br>
><br>
> ...<br>
><br>
> MyPrincipal myPrincipal = callerPrincipal.unwrap();<br>
><br>
<br>
Was more thinking about:<br>
<br>
MyPrincipal myPrincipal = callerPrincipal.unwrap(<wbr>MyPrincipal.class);<br>
<br>
<br>
><br>
><br>
> vs<br>
><br>
><br>
> Security context:<br>
><br>
> @Inject SecurityContext securityContext;<br>
><br>
> ...<br>
><br>
> MyPrincipal myPrincipal = securityContext.<wbr>getCallerPrincipal();<br>
><br>
> Spot the differences ;)<br>
><br>
<br>
Here you can get a PrincipalFacade which limits MyPrincipal to getName()<br>
only, this is perfectly valid per spec.<br>
<br>
<br>
><br>
><br>
><br>
>> In other words either Principal is removed from CDI spec<br>
>><br>
><br>
> I think this should be done anyway. The build-in bean for Principal would<br>
> be more at home with the Security API spec. I would be happy to take it in<br>
> ;)<br>
><br>
> (likewise, the build-in bean for HttpServletRequest etc should be with the<br>
> Servlet spec)<br>
><br>
><br>
><br>
>> or it stays but it should be extended to be made usable IMHO.<br>
>><br>
><br>
> What CDI could provide and which has been discussed before, is a method to<br>
> get the real bean from a proxy. E.g.<br>
><br>
> @Inject CallerPrincipal callerPrincipal;<br>
> @Inject BeanManager beanManager;<br>
><br>
> ...<br>
><br>
> MyPrincipal myPrincipal = beanManager.unwrap(<wbr>callerPrincipal);<br>
><br>
<br>
Well this would assume we can do it for all beans and a lot of cases would<br>
be problematic cause it is just not doable :s...but would help if we find a<br>
compromise for other beans too :)<br>
<br>
<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>><br>
>><br>
>> Romain Manni-Bucau<br>
>> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a>> | Blog<br>
>> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a>> | Old Blog<br>
>> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.<wbr>com</a>> | Github<br>
>> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a>> | LinkedIn<br>
>> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a>> | JavaEE Factory<br>
>> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a>><br>
>><br>
>> 2017-04-26 17:11 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> We discussed this very issue in the Security API EG as well. In the<br>
>>> Security API the actual type *MUST* be retained as per the spec definition.<br>
>>><br>
>>> The problem in CDI, at least in Weld, is that a proxy is injected. This<br>
>>> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where<br>
>>> AbstractEEBean does:<br>
>>><br>
>>> public abstract class AbstractEEBean<T> extends<br>
>>> AbstractStaticallyDecorableBui<wbr>ltInBean<T> {<br>
>>><br>
>>> private final T proxy;<br>
>>><br>
>>> protected AbstractEEBean(Class<T> type, Callable<T> callable,<br>
>>> BeanManagerImpl beanManager) {<br>
>>> super(beanManager, type);<br>
>>> this.proxy = new ProxyFactory<T>(beanManager.<wbr>getContextId(),<br>
>>> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(<wbr>type,<br>
>>> new CallableMethodHandler(<wbr>callable)));<br>
>>> }<br>
>>> // ...<br>
>>> }<br>
>>><br>
>>> I'm not even sure if it's possible to downcast the proxy to the required<br>
>>> runtime type.<br>
>>><br>
>>> Also note that the Principal can change during the request. The simplest<br>
>>> case is when during an http request HttpServletRequest#logout is called.<br>
>>><br>
>>> Kind regards,<br>
>>> Arjan Tijms<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <<br>
>>> <a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a>> wrote:<br>
>>><br>
>>>> Hey guys<br>
>>>><br>
>>>><br>
>>>> I raised a bug against the Weld guys, but think its worth an EG<br>
>>>> discussion. When a Principal object is injected, the only type it has is<br>
>>>> Principal. It does not retain the actual type used at runtime. This threw<br>
>>>> me off on some Keycloak integration I'm working on (in $dayjob). So I was<br>
>>>> wondering, is this expected from our POV or should it retain the types of<br>
>>>> the actual runtime instance?<br>
>>>><br>
>>>><br>
>>>> John<br>
>>>><br>
>>>> ------------------------------<br>
>>>> NOTICE: This e-mail message and any attachments may contain<br>
>>>> confidential, proprietary, and/or privileged information which should be<br>
>>>> treated accordingly. If you are not the intended recipient, please notify<br>
>>>> the sender immediately by return e-mail, delete this message, and destroy<br>
>>>> all physical and electronic copies. Thank you.<br>
>>>><br>
>>>> ______________________________<wbr>_________________<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/<wbr>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 (<a href="http://www.apache.org/license" rel="noreferrer" target="_blank">http://www.apache.org/license</a><br>
>>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the<br>
>>>> provider waives all patent and other intellectual property rights inherent<br>
>>>> in such information.<br>
>>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<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/<wbr>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 (<a href="http://www.apache.org/license" rel="noreferrer" target="_blank">http://www.apache.org/license</a><br>
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the<br>
>>> provider waives all patent and other intellectual property rights inherent<br>
>>> in such information.<br>
>>><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1afdba6f/attachment.html" rel="noreferrer" target="_blank">http://lists.jboss.org/<wbr>pipermail/cdi-dev/attachments/<wbr>20170426/1afdba6f/attachment.<wbr>html</a><br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<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/<wbr>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/<wbr>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 77, Issue 11<br>
******************************<wbr>*********<br>
</blockquote></div><br></div></div>