[cdi-dev] Types of Principal object

arjan tijms arjan.tijms at gmail.com
Wed Apr 26 12:41:03 EDT 2017 

Hi,

On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <werner.keil at gmail.com> wrote:

> Not sure, if I follow you on that?
>
> java.security.Principal is not part of the CDI spec at all and only used
> by a special subclass of
> AbstractEEBean<T>
>

I think what Romain intended here is that the build-in Bean<T> for
Principal is removed from CDI and moved to e.g. the Java EE Security spec.
In case of Weld that would be org.jboss.weld.bean.builtin.ee.PrincipalBean

(see
http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.servlet/weld-servlet/2.3.0.Beta3/org/jboss/weld/bean/builtin/ee/PrincipalBean.java#PrincipalBean
)

The Principal type itself is of course not part of CDI, but part of Java SE.

Btw, a CDI extension can easily scan the application for occurrences of
Injection Points that have a Principal subtype as their target, and then
dynamically add a specific Bean<T> for that. This is what we do in
OmniFaces as well.

See

* Collecting types:
https://github.com/omnifaces/omnifaces/blob/develop/src/main/java/org/omnifaces/cdi/param/ParamExtension.java#L61

* Adding a Bean<T> for each encountered type:
https://github.com/omnifaces/omnifaces/blob/develop/src/main/java/org/omnifaces/cdi/param/ParamExtension.java#L74

Kind regards,
Arjan Tijms




>
>
> The problem seems the generic T which Java at this point is unable to know
> about at runtime.
>
> It makes no difference, if you had
> PrincipalBean extends AbstractEEBean<Principal>
> or a
> StringBean extends AbstractBuiltInBean<String>
>
> Even created a JUnit test in
>
> https://github.com/unitsofmeasurement/uom-se/
> blob/master/src/test/java/tec/uom/se/AbsUnitTest.java
>
> Which under Java 8 returns
>
> "java.lang.reflect.TypeVariable<D>"
>
> No sign of "Length" which is what you'd hoped for (maybe we did not dig
> deep enough, maybe it won't work until a future Java version?)
>
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:46 PM, <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. Re: Types of Principal object (Romain Manni-Bucau)
>>    2. Re: Types of Principal object (Werner Keil)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 26 Apr 2017 17:41:08 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: arjan tijms <arjan.tijms at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=UNkuEGQg at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> that's why security API needs a more typed API acting as an handler and
>> not
>> as a contextual instance, it would allow to unwrap the actual instance
>> (like most specs do) but at CDI level it should also be possible. If not
>> we
>> have this built-in bean never working until you add another not mandatory
>> spec - for CDI level. In other words either Principal is removed from CDI
>> spec or it stays but it should be extended to be made usable IMHO.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 17:11 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>>
>> > Hi,
>> >
>> > We discussed this very issue in the Security API EG as well. In the
>> > Security API the actual type *MUST* be retained as per the spec
>> definition.
>> >
>> > The problem in CDI, at least in Weld, is that a proxy is injected. This
>> > happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> where
>> > AbstractEEBean does:
>> >
>> > public abstract class AbstractEEBean<T> extends
>> > AbstractStaticallyDecorableBuiltInBean<T> {
>> >
>> >     private final T proxy;
>> >
>> >     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> > BeanManagerImpl beanManager) {
>> >         super(beanManager, type);
>> >         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> > type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
>> new
>> > CallableMethodHandler(callable)));
>> >     }
>> >     // ...
>> > }
>> >
>> > I'm not even sure if it's possible to downcast the proxy to the required
>> > runtime type.
>> >
>> > Also note that the Principal can change during the request. The simplest
>> > case is when during an http request HttpServletRequest#logout is called.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> > On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
>> john.ament at spartasystems.com>
>> > wrote:
>> >
>> >> Hey guys
>> >>
>> >>
>> >> I raised a bug against the Weld guys, but think its worth an EG
>> >> discussion.  When a Principal object is injected, the only type it has
>> is
>> >> Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> >> me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> >> wondering, is this expected from our POV or should it retain the types
>> of
>> >> the actual runtime instance?
>> >>
>> >>
>> >> John
>> >>
>> >> ------------------------------
>> >> NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> >> proprietary, and/or privileged information which should be treated
>> >> accordingly. If you are not the intended recipient, please notify the
>> >> sender immediately by return e-mail, delete this message, and destroy
>> all
>> >> physical and electronic copies. Thank you.
>> >>
>> >> _______________________________________________
>> >> 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/license
>> >> s/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.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/ad930662/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 26 Apr 2017 17:44:04 +0200
>> From: Werner Keil <werner.keil at gmail.com>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=oT_A at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Seems the title of the thread was also not "reified" in this case.
>> Sometimes reply just works, but if it was lost, sorry for that.
>>
>> Werner
>>
>>
>> On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <werner.keil at gmail.com>
>> wrote:
>>
>> > We had similar challenges and discussions even before JSR 363 about
>> > knowing what type of quantity you're dealing with types like
>> >
>> > Unit<Q extends Quantity <http://unitsofmeasurement.git
>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>> >
>> > I can only confirm Arjan's impression. And I had numerous conversations
>> > with Andrew Kennedy, the Chief Architect behind the F# Units of
>> Measurement
>> > support and other .NET libraries about it. Where he mentioned
>> shortcomings
>> > of the Java language especially the lack of Reified Generics (
>> > http://stackoverflow.com/questions/31876372/what-is-reification), which
>> > C#, F# or other .NET languages got, but Java won't at least not until
>> Java
>> > 10, 11 or even later.
>> >
>> > I tried a lot between 2010 and now but so far none of these Reflection
>> > tricks and approaches were stable enough, so not sure, if it'll work any
>> > better in this case (unless you implement CDI in C#;-)
>> >
>> > Werner
>> >
>> >
>> > On Wed, Apr 26, 2017 at 5:29 PM, <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. Types of Principal object (John Ament)
>> >>    2. Re: Types of Principal object (Romain Manni-Bucau)
>> >>    3. Re: Types of Principal object (Matej Novotny)
>> >>    4. Re: Types of Principal object (arjan tijms)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Wed, 26 Apr 2017 13:54:57 +0000
>> >> From: John Ament <john.ament at spartasystems.com>
>> >> Subject: [cdi-dev] Types of Principal object
>> >> To: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <CY4PR04MB048607BF779F8680ED5CE53898110 at CY4PR04MB0486.namprd
>> >> 04.prod.outlook.com>
>> >>
>> >> Content-Type: text/plain; charset="iso-8859-1"
>> >>
>> >> Hey guys
>> >>
>> >>
>> >> I raised a bug against the Weld guys, but think its worth an EG
>> >> discussion.  When a Principal object is injected, the only type it has
>> is
>> >> Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> >> me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> >> wondering, is this expected from our POV or should it retain the types
>> of
>> >> the actual runtime instance?
>> >>
>> >>
>> >> John
>> >>
>> >> ________________________________
>> >> NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> >> proprietary, and/or privileged information which should be treated
>> >> accordingly. If you are not the intended recipient, please notify the
>> >> sender immediately by return e-mail, delete this message, and destroy
>> all
>> >> physical and electronic copies. Thank you.
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> >> 6/b6740722/attachment-0001.html
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 2
>> >> Date: Wed, 26 Apr 2017 16:38:01 +0200
>> >> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> >> Subject: Re: [cdi-dev] Types of Principal object
>> >> To: John Ament <john.ament at spartasystems.com>
>> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <CACLE=7N=pkvZDX3ULCFAK2Fhw8-bH0pbOsqctqsbkPhKk8i1VA at mail.gm
>> >> ail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> Hi John,
>> >>
>> >> agree CDI/security integration (mainly through Principal bean) is
>> >> completely unusable in practise cause Principal type is too simple
>> (name
>> >> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>> >> https://issues.jboss.org/browse/CDI-597.
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> >> <http://rmannibucau.wordpress.com> | Github <
>> >> https://github.com/rmannibucau> |
>> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> >> <https://javaeefactory-rmannibucau.rhcloud.com>
>> >>
>> >> 2017-04-26 15:54 GMT+02:00 John Ament <john.ament at spartasystems.com>:
>> >>
>> >> > Hey guys
>> >> >
>> >> >
>> >> > I raised a bug against the Weld guys, but think its worth an EG
>> >> > discussion.  When a Principal object is injected, the only type it
>> has
>> >> is
>> >> > Principal.  It does not retain the actual type used at runtime.  This
>> >> threw
>> >> > me off on some Keycloak integration I'm working on (in $dayjob).  So
>> I
>> >> was
>> >> > wondering, is this expected from our POV or should it retain the
>> types
>> >> of
>> >> > the actual runtime instance?
>> >> >
>> >> >
>> >> > John
>> >> >
>> >> > ------------------------------
>> >> > NOTICE: This e-mail message and any attachments may contain
>> >> confidential,
>> >> > proprietary, and/or privileged information which should be treated
>> >> > accordingly. If you are not the intended recipient, please notify the
>> >> > sender immediately by return e-mail, delete this message, and destroy
>> >> all
>> >> > physical and electronic copies. Thank you.
>> >> >
>> >> > _______________________________________________
>> >> > 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.
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> >> 6/19976ebd/attachment-0001.html
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 3
>> >> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>> >> From: Matej Novotny <manovotn at redhat.com>
>> >> Subject: Re: [cdi-dev] Types of Principal object
>> >> To: John Ament <john.ament at spartasystems.com>
>> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <1098875365.1348630.1493218120014.JavaMail.zimbra at redhat.com>
>> >> Content-Type: text/plain; charset=utf-8
>> >>
>> >> Hey John,
>> >>
>> >> just to shed some light.
>> >> One of the reasons it works this way is because the types the actual
>> >> Principal has might not be proxyable.
>> >> And spec requires all built-in beans to be decorable - e.g. you need
>> them
>> >> to be proxyable (although the added value of principal decorator is
>> ...eh,
>> >> disputable at best?).
>> >>
>> >> Therefore, it is safer/viable to create a proxyable wrapper object
>> which
>> >> implements Principal only and delegetas calls (that's what Weld does).
>> >>
>> >> Otherwise I agree it could be nice to ahve a way to cast the object as
>> >> the pure Principal interface doesn't help much.
>> >>
>> >> Matej
>> >>
>> >> ----- Original Message -----
>> >> > From: "John Ament" <john.ament at spartasystems.com>
>> >> > To: "cdi-dev" <cdi-dev at lists.jboss.org>
>> >> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>> >> > Subject: [cdi-dev] Types of Principal object
>> >> >
>> >> >
>> >> >
>> >> > Hey guys
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > I raised a bug against the Weld guys, but think its worth an EG
>> >> discussion.
>> >> > When a Principal object is injected, the only type it has is
>> Principal.
>> >> It
>> >> > does not retain the actual type used at runtime. This threw me off on
>> >> some
>> >> > Keycloak integration I'm working on (in $dayjob). So I was
>> wondering, is
>> >> > this expected from our POV or should it retain the types of the
>> actual
>> >> > runtime instance?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > John
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > NOTICE: This e-mail message and any attachments may contain
>> >> confidential,
>> >> > proprietary, and/or privileged information which should be treated
>> >> > accordingly. If you are not the intended recipient, please notify the
>> >> sender
>> >> > immediately by return e-mail, delete this message, and destroy all
>> >> physical
>> >> > and electronic copies. Thank you.
>> >> >
>> >> > _______________________________________________
>> >> > 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: 4
>> >> Date: Wed, 26 Apr 2017 17:11:11 +0200
>> >> From: arjan tijms <arjan.tijms at gmail.com>
>> >> Subject: Re: [cdi-dev] Types of Principal object
>> >> To: John Ament <john.ament at spartasystems.com>
>> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA at mail.
>> >> gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> Hi,
>> >>
>> >> We discussed this very issue in the Security API EG as well. In the
>> >> Security API the actual type *MUST* be retained as per the spec
>> >> definition.
>> >>
>> >> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> >> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> >> where
>> >> AbstractEEBean does:
>> >>
>> >> public abstract class AbstractEEBean<T> extends
>> >> AbstractStaticallyDecorableBuiltInBean<T> {
>> >>
>> >>     private final T proxy;
>> >>
>> >>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> >> BeanManagerImpl beanManager) {
>> >>         super(beanManager, type);
>> >>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> >> type,
>> >> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>> >> CallableMethodHandler(callable)));
>> >>     }
>> >>     // ...
>> >> }
>> >>
>> >> I'm not even sure if it's possible to downcast the proxy to the
>> required
>> >> runtime type.
>> >>
>> >> Also note that the Principal can change during the request. The
>> simplest
>> >> case is when during an http request HttpServletRequest#logout is
>> called.
>> >>
>> >> Kind regards,
>> >> Arjan Tijms
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
>> john.ament at spartasystems.com
>> >> >
>> >> wrote:
>> >>
>> >> > Hey guys
>> >> >
>> >> >
>> >> > I raised a bug against the Weld guys, but think its worth an EG
>> >> > discussion.  When a Principal object is injected, the only type it
>> has
>> >> is
>> >> > Principal.  It does not retain the actual type used at runtime.  This
>> >> threw
>> >> > me off on some Keycloak integration I'm working on (in $dayjob).  So
>> I
>> >> was
>> >> > wondering, is this expected from our POV or should it retain the
>> types
>> >> of
>> >> > the actual runtime instance?
>> >> >
>> >> >
>> >> > John
>> >> >
>> >> > ------------------------------
>> >> > NOTICE: This e-mail message and any attachments may contain
>> >> confidential,
>> >> > proprietary, and/or privileged information which should be treated
>> >> > accordingly. If you are not the intended recipient, please notify the
>> >> > sender immediately by return e-mail, delete this message, and destroy
>> >> all
>> >> > physical and electronic copies. Thank you.
>> >> >
>> >> > _______________________________________________
>> >> > 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.
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> >> 6/206ff811/attachment.html
>> >>
>> >> ------------------------------
>> >>
>> >> _______________________________________________
>> >> 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/license
>> >> s/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 77, Issue 8
>> >> **************************************
>> >>
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/ebea1962/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> 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/license
>> s/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 77, Issue 10
>> ***************************************
>>
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/f3eddf0e/attachment-0001.html

More information about the cdi-dev mailing list