[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Jozef Hartinger
jharting at redhat.com
Thu Jan 15 05:22:20 EST 2015
On 01/15/2015 11:04 AM, Mark Struberg wrote:
> Weld does that, really?
>
> so if I have
> @Named("such.a.broken.pattern")
> public class MyFunnyBean
>
> then weld would properly resolve the following EL?
>
> #{such.a.broken.pattern}
>
>
> really?
Yes, that's exactly what Weld has been doing since 2009 (as required by
the spec) ;-)
>
> If not then I will of course create a Weld blocker bug (*).
In that case this would be a reasonable thing to do.
>
>
> LieGrue,
> strub
>
>
>
> (*) just joking, but I hope you got my point.
>
>
>
> ----- Original Message -----
>> From: Jozef Hartinger <jharting at redhat.com>
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>; Martin Kouba <mkouba at redhat.com>
>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Thursday, 15 January 2015, 10:46
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
>>
>> After looking into the spec again it became apparent to me that this is
>> not an issue of a poorly chosen name for a built-in bean as it may look
>> like at the first glance. Instead, CDI seems to define bean names on top
>> of EL. It says:
>>
>> "A valid bean name is a period-separated list of valid EL
>> identifiers."
>>
>> It even goes further and says:
>> "The following strings are valid bean names: com.acme.settings"
>>
>> This means that a bean name *does not have to be a valid EL name*. It
>> has to be a period-separated list of valid EL identifiers i.e. a valid
>> EL expression. This implies that a CDI implementation needs to have a
>> special mechanism for resolving a bean from an EL expression which
>> recognizes the concept of bean names built on top of EL names (like Weld
>> does).
>>
>>
>> On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote:
>>> -1 to provide a bean "javax" it is worse than hacking EL to
>> support it
>>> since it also impacts other cases.
>>>
>>> That said as Mark showed not having it is not a blocker for a user so
>>> why not just adding the "SHOULD support for EL" since spec(s)
>> dont
>>> proove it is mandatory since EE 6.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>> Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>>>>>> This has been a requirement since version 1.0, a number of
>> years. How has
>>>>>> OWB
>>>>>> managed to not be compliant with this to date?
>>>>>
>>>>> I quickly checked the logs for the CDI-1.0 tck run and it seems
>> that the
>>>>> test even passes if
>> #{javax.enterprise.context.conversation.id} resolves to
>>>>> null. Not sure why though.
>>>>>
>>>>>
>>>>> The other point is that OWB doesn't claim to pass the full TCK
>> but only
>>>>> the SE parts. This is the same as for Weld. With the CDI container
>> alone you
>>>>> simply cannot pass those.
>>>>>
>>>>> The EE part is being tested when being integrated into an EE server
>>>>> (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an
>>>>> additional ELResolver for it? But I honestly doubt it.
>>>>>
>>>>>
>>>>>
>>>>>> Yes, but we still have to implement the existing spec as it
>> stands.
>>>>> I understand that we cannot make sure that nobody ever used this.
>> But it
>>>>> contradicts other (older) EE specs and the current wording is imo
>> not that
>>>>> clear that it is really mandatory to support it (as outlined in my
>> other
>>>>> mail).
>>>>>
>>>>> There is also a very easy hack to get this back if a user really
>> wants:
>>>>> @Named("javax")
>>>>> public class ConversationElHelperJavax {
>>>>>
>>>>> public ConversationElHelperEnterprise getEnterprise() {..}
>>>>>
>>>>>
>>>>> public class ConversationElHelperEnterprise {
>>>>> public ConversationElHelperConversation getConversation()
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>> and the most inner class just returns the current Conversation
>> instance.
>>>>>
>>>>> Thus a user can totally easily get this behaviour by himself IF he
>> needs
>>>>> it!
>>>> Wouldn't be better (from the user point of view) to provide such a
>> bean in
>>>> OWB? Just for compatibility reasons. Of course, we should also
>> explicitly
>>>> state that "javax.enterprise.context.conversation" is
>> deprecated and users
>>>> and encouraged not to use it...
>>>>
>>>> Moreover, I think there are more users using
>>>> "javax.enterprise.context.conversation" than users having a
>> CDI bean with
>>>> name "javax".
>>>>
>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Pete Muir <pmuir at redhat.com>
>>>>>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev
>>>>>> <cdi-dev at lists.jboss.org>
>>>>>> Sent: Wednesday, 14 January 2015, 14:35
>>>>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,
>> "." is not valid
>>>>>> in an EL name.
>>>>>>
>>>>>>
>>>>>>> On 14 Jan 2015, at 13:31, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>>> wrote:
>>>>>>> Well ATM there is no requirement it works
>>>>>> There is a requirement that everything in the spec should work,
>> yes.
>>>>>>> and I'm convinced another
>>>>>>> (better) solution will be found for coming versions
>>>>>> Yes, but we still have to implement the existing spec as it
>> stands.
>>>>>>> so I would really
>>>>>>> avoid to introduce a workaround on which users will not
>> be able to
>>>>>>> rely.
>>>>>> This has been a requirement since version 1.0, a number of
>> years. How has
>>>>>> OWB
>>>>>> managed to not be compliant with this to date?
>>>>>>
>>>>>>> Also Weld implementation breaks some valid usages of EL
>> (since
>>>>>>> it is not done for javax only, right?).
>>>>>> For example?
>>>>>>
>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2015-01-14 14:28 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>> I think you need to use the workaround of Weld. It
>> works, and
>>>>>> implements the spec as it stands, and means the test will pass.
>> You can
>>>>>> argue
>>>>>> that the spec is not written in such a way that requires this
>> to work,
>>>>>> but you
>>>>>> are splitting hairs at this point, and it was the intent of the
>> 1.0 EG
>>>>>> that it
>>>>>> would work the way Weld implemented it.
>>>>>>>>> On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>>>>>> <rmannibucau at gmail.com> wrote:
>>>>>>>>> well issue is when you activate EL + CDI, if you
>> respect both specs
>>>>>>>>> #{javax.enterprise.context.conversation.id}
>> should fail -
>>>>>> agree we can
>>>>>>>>> always use the *workaround* of Weld but this is
>> actually not
>>>>>> mandated
>>>>>>>>> by any spec excepted this test which was IMO an
>> interpolation.
>>>>>> That's
>>>>>>>>> why i think this test shouldnt be kept even for
>> 1.x versions.
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> @rmannibucau
>>>>>>>>> http://www.tomitribe.com
>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-01-14 14:09 GMT+01:00 Martin Kouba
>> <mkouba at redhat.com>:
>>>>>>>>>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau
>> napsal(a):
>>>>>>>>>>> If "there is no problem with not
>> passing a particular
>>>>>> test from the EL
>>>>>>>>>>> spec" then there is no problem with
>> not passing a
>>>>>> particular test from
>>>>>>>>>>> the CDI spec at EE level which seems
>> wrong to me.
>>>>>>>>>>> Globally I'd just remove this test
>> and keep it in Weld
>>>>>> vendor specific
>>>>>>>>>>> features.
>>>>>>>>>>>
>>>>>>>>>>> @martin: my 1) was for EL spec not CDI.
>>>>>>>>>>>
>>>>>>>>>>> About 2
>>>>>> "#{javax.enterprise.context.conversation.id}" is
>> legal if id
>>>>>>>>>>> is a property of conversation which is a
>> property of
>>>>>> context which is
>>>>>>>>>>> a property of enterprise which is a
>> property of javax which
>>>>>> is clearly
>>>>>>>>>>> not what is desired and opposed to what
>> is in the CDI spec.
>>>>>>>>>>
>>>>>>>>>> Sure. But EL cannot test this. From it's
>> point of view the
>>>>>>>>>>
>> "#{javax.enterprise.context.conversation.id}"
>>>>>> expression is ok. From CDI
>>>>>>>>>> point of view the name is wrong and cannot
>> be used as it is...
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> @rmannibucau
>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-01-14 13:12 GMT+01:00 Pete Muir
>>>>>> <pmuir at redhat.com>:
>>>>>>>>>>>> I agree with Martin. We *should* fix
>> this situation in
>>>>>> the long term,
>>>>>>>>>>>> which
>>>>>>>>>>>> is what I proposed. However in the
>> short term there is
>>>>>> no problem with
>>>>>>>>>>>> not
>>>>>>>>>>>> passing a particular test from the
>> EL spec.
>>>>>> Additionally this is provably
>>>>>>>>>>>> implementable as Weld implements
>> this, and many Java EE
>>>>>> containers pass.
>>>>>>>>>>>> As
>>>>>>>>>>>> there are no other spec defined
>> beans javax, then we do
>>>>>> not conflict with
>>>>>>>>>>>> any other spec by implementing it
>> this way.
>>>>>>>>>>>> On 14 Jan 2015, at 12:10, Martin
>> Kouba
>>>>>> <mkouba at redhat.com> wrote:
>>>>>>>>>>>> Dne 14.1.2015 v 12:43 Romain
>> Manni-Bucau napsal(a):
>>>>>>>>>>>> well there are 2 points:
>>>>>>>>>>>> 1) a test should be added for it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There was a CDI TCK test since 1.1
>>>>>>>>>>>>
>>>>>>>>>>>>
>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>>>>> It has been modified a week ago (see
>> also CDITCK-462)
>>>>>> not to use
>>>>>>>>>>>>
>> "javax.enterprise.context.conversation.id".
>>>>>>>>>>>> 2) test or not being certified means
>> respecting the
>>>>>> spec (pdf, javadoc
>>>>>>>>>>>> + tests themselve)
>>>>>>>>>>>>
>>>>>>>>>>>> So if there is this test a container
>> can't be
>>>>>> certified for EL + CDI
>>>>>>>>>>>> at the same time
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think it's a
>> problem. An EL TCK test
>>>>>> can't evaluate
>>>>>> "#{javax.enterprise.context.conversation.id}" as
>> an illegal
>>>>>> expression -
>>>>>>>>>>>> it's obviously legal. The
>> problem is
>>>>>>>>>>>>
>> "javax.enterprise.context.conversation.id"
>>>>>> can't be simply used as a bean
>>>>>>>>>>>> name. If it is, a workaround is
>> needed (see also
>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir
>>>>>> <pmuir at redhat.com>:
>>>>>>>>>>>> Which EL test?
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 Jan 2015, at 11:30, Romain
>> Manni-Bucau
>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> then it will not pass EL one
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir
>>>>>> <pmuir at redhat.com>:
>>>>>>>>>>>> No, a Java EE container needs to
>> pass this test.
>>>>>>>>>>>> On 14 Jan 2015, at 11:21, Romain
>> Manni-Bucau
>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> so it means a JavaEE container will
>> not pass this test
>>>>>> but it is not an
>>>>>>>>>>>> issue?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir
>>>>>> <pmuir at redhat.com>:
>>>>>>>>>>>> I don’t think they should be
>> excluded. The spec isn’t
>>>>>> ambiguous about
>>>>>>>>>>>> this,
>>>>>>>>>>>> and it is supportable.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 Jan 2015, at 11:13, Jozef
>> Hartinger
>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>>>>> So for CDI 1.2 the test that tests
>> this should not be
>>>>>> excluded after all,
>>>>>>>>>>>> correct?
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir
>> wrote:
>>>>>>>>>>>> We need to go for both (A) and (B).
>>>>>>>>>>>>
>>>>>>>>>>>> We would need to deprecate the
>> existing name before we
>>>>>> can allow it to
>>>>>>>>>>>> not
>>>>>>>>>>>> be supported. This means CDI 3. So I
>> would suggest we
>>>>>> deprecate it in 2,
>>>>>>>>>>>> add
>>>>>>>>>>>> an alternative that can be used, and
>> then consider
>>>>>> removing it in CDI 3.
>>>>>>>>>>>> In
>>>>>>>>>>>> the meantime for CDI 2, we will need
>> to improve the TCK
>>>>>> to check this
>>>>>>>>>>>> more
>>>>>>>>>>>> carefully.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 Jan 2015, at 10:09, Romain
>> Manni-Bucau
>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> +1 for B (IMO it is not used that
>> much)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef
>> Hartinger
>>>>>> <jharting at redhat.com>:
>>>>>>>>>>>> I think further action is needed on
>> this. Now that it
>>>>>> has been confirmed
>>>>>>>>>>>> that
>> "javax.enterprise.context.conversation"
>>>>>> itself is not a valid EL
>>>>>>>>>>>> name we should either:
>>>>>>>>>>>>
>>>>>>>>>>>> A) Require all CDI implementations
>> to adapt the
>>>>>> property-based approach
>>>>>>>>>>>> which allows this to be implemented
>> portably (as Weld
>>>>>> does)
>>>>>>>>>>>> B) Declare publicly that although
>> the CDI spec declares
>>>>>> the given name,
>>>>>>>>>>>> it is a bug and applications should
>> not use the name.
>>>>>> (What about
>>>>>>>>>>>> compatibility with existing
>> applications?)
>>>>>>>>>>>> Jozef
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/08/2015 09:27 AM, Mark
>> Struberg wrote:
>>>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>>>
>>>>>>>>>>>> I've received an answer
>> regarding our EL question
>>>>>> from the EL Spec Lead.
>>>>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tuesday, 6 January 2015, 23:14,
>> Edward Burns
>>>>>> <edward.burns at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>>>
>>>>>>>>>>>> To close this out, no, "."
>> is not valid in an
>>>>>> EL name. An EL name
>>>>>>>>>>>> must
>>>>>>>>>>>> be a java identifier. I'm told
>> this was discussed
>>>>>> by Pete a long time
>>>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>>>>
>>>>>>>>>>>> Ed
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> | edward.burns at oracle.com | office:
>> +1 407 458 0017
>>>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>>>>
>>>>>>>>>>>>
>> _______________________________________________
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>> _______________________________________________
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>> _______________________________________________
>>> 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.
>>
More information about the cdi-dev
mailing list