[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Mark Struberg
struberg at yahoo.de
Thu Jan 15 05:04:54 EST 2015
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?
If not then I will of course create a Weld blocker bug (*).
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