<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Let me fix the terminology here: "Multiple BeanManagers" is a
misleading expression because it is not clear if we are talking
about multiple BM within a single CDI container or separate
containers. What Antoine had in mind (I think) is multiple CDI
container instances. Therefore, let's use "multiple CDI container
instances" hereafter in order not to get confused.<br>
<br>
This topic was discussed before. There are a few tricky parts that
can be resolved more or less (e.g. CDI.current()). We may not
necessarily need to specify this but we should make sure we do not
anyhow prevent or make it unnecessarily difficult for CDI
implementations to implement "multiple CDI container instances"
running in parallel.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/04/2015 10:52 AM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote
cite="mid:CACLE=7MOw0Cha1NPhJrKQhqY-0OP-2GJk2gJWkfpsqxaE8tgbQ@mail.gmail.com"
type="cite">
<div dir="ltr">@Antoine: to boot multiple BM it would need to
break contextuality of CDI, one way being to forbid any
serialization (not a big constraint in SE). In this case
container is bound to a bean manager which changes the API Jozef
propose</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a moz-do-not-send="true"
href="https://twitter.com/rmannibucau"
target="_blank">@rmannibucau</a> | <a
moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">Blog</a> | <a
moz-do-not-send="true"
href="https://github.com/rmannibucau"
target="_blank">Github</a> | <a
moz-do-not-send="true"
href="https://www.linkedin.com/in/rmannibucau"
target="_blank">LinkedIn</a> | <a
moz-do-not-send="true"
href="http://www.tomitribe.com"
target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">2015-03-04 10:49 GMT+01:00 Antoine
Sabot-Durand <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>Hi John,</div>
<div><br>
</div>
<div>I think it could be a good idea to write down all of
these to have a more stable doc for discussion. You
should update the google doc with the result of this
discussion.</div>
<div><br>
</div>
<div>I agree with the following points in this thread :</div>
<div><br>
</div>
<div>- Minimize the number of new Class / Interface. CDI
and CDIProvider usage is still not very clear for end
user so we should add the strict minimum and try to
enhance existing API / SPI when possible</div>
<div>- Be able to bootstrap CDI without returning
BeanManager (env if the API give possibility to access
it if needed). End user don’t need that : CDI app can
start with an observer for instance</div>
<div><br>
</div>
<div>Something not dealt with but that we should keep in
mind :</div>
<div>- Providing a Java SE solution that could be easily
used for a servlet bootstrap of CDI. I don’t know if
we’ll standardize this but we definitely should keep
this use case in mind</div>
<div><br>
</div>
<div>and my bonus, it’s out of scope but I didn’t see
anytime there that prevent this nice to have:</div>
<div>- support the possibility to boot multiple
BeanManager in Java SE.</div>
<div><br>
</div>
<div>Antoine</div>
<div><br>
</div>
<br>
<div>
<blockquote type="cite">
<div>Le 1 mars 2015 à 15:13, John D. Ament <<a
moz-do-not-send="true"
href="mailto:john.d.ament@gmail.com"
target="_blank">john.d.ament@gmail.com</a>> a
écrit :</div>
<div>
<div class="h5"><br>
<div>
<div dir="ltr">So, I think I've gathered enough
feedback at this point, and seen some of the
API changes. I'll hopefully be including some
doc changes this week, but one question - do
we want to start the SE specific stuff as its
own asciidoc file?
<div><br>
</div>
<div>Changes made:</div>
<div><br>
</div>
<div>- Changed return value to
CDI<Object> to provide better
capability out of the box.</div>
<div>- Added AutoCloseable to CDIContainer,
provided default implementation of calling
shutdown.</div>
<div>- Added synchronization support to the
method body that retrieves the singleton
instance (BTW, I'm not sure if this is even
useful TBH as each impl, including the RI,
needs to provide this class in its own
format).</div>
<div>- Made the params map typed to
<String,Object></div>
<div><br>
</div>
<div>@Romain Your case isn't really
supportable yet, until we have static
injection support. You'd still have to have
a managed version of Runner to work against.</div>
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">On Sat, Feb 28,
2015 at 4:11 PM Romain Manni-Bucau <<a
moz-do-not-send="true"
href="mailto:rmannibucau@gmail.com"
target="_blank">rmannibucau@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<p dir="ltr">Yes but not the way to get
an instance. Even Unmanaged does it.</p>
<p dir="ltr">What can be awesome is to
have static inject for it:</p>
<p dir="ltr">public class Runner {</p>
<p dir="ltr">@Inject<br>
private static MyMain main;</p>
<p dir="ltr">public static void
main(String[] arg) {<br>
try (CDIContainer c =
CDIContainer.newContainer()) {<br>
main.doWork();<br>
}<br>
}</p>
<p dir="ltr">}</p>
<p dir="ltr">And not a single additional
line :).<br>
</p>
<div class="gmail_quote">Le 28 févr.
2015 19:05, "John D. Ament" <<a
moz-do-not-send="true"
href="mailto:john.d.ament@gmail.com"
target="_blank">john.d.ament@gmail.com</a>>
a écrit :</div>
<div class="gmail_quote"><br
type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">Maybe I'm misreading,
but I don't see us adding another
API to do the same thing here -
we're introducing new
functionality.
<div><br>
</div>
<div>CDIContainer/Loader on
startup/shutdown of the
application</div>
<div><br>
</div>
<div>CDI for runtime usage within
the application to interact with
the container.</div>
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">On Fri,
Feb 27, 2015 at 3:40 AM Romain
Manni-Bucau <<a
moz-do-not-send="true"
href="mailto:rmannibucau@gmail.com"
target="_blank">rmannibucau@gmail.com</a>>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">sure
I fully agree excepted I
think introducing yet
another API to do<br>
the same thing is not good
so super tempting to skip it
and wait for<br>
feedbacks rather than
introducing it eagerly.<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a moz-do-not-send="true"
href="http://www.tomitribe.com/"
target="_blank">http://www.tomitribe.com</a><br>
<a moz-do-not-send="true"
href="http://rmannibucau.wordpress.com/"
target="_blank">http://rmannibucau.wordpress.com</a><br>
<a moz-do-not-send="true"
href="https://github.com/rmannibucau"
target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
2015-02-27 8:05 GMT+01:00
Jozef Hartinger <<a
moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>>:<br>
> My point is that from
the application perspective,
the user obtains one<br>
> container handle for
eventual shutdown
(CDIContainer) and then
looks up a<br>
> different container
handle (CDI) that they can
use for real work (lookup /<br>
> event dispatch / etc.)
It would be cleaner if the
container gave away a<br>
> single handle that can
do all of that.<br>
><br>
><br>
> On 02/26/2015 05:42 PM,
Romain Manni-Bucau wrote:<br>
><br>
> Not sure I get how a
CDI instance can help.<br>
><br>
> But
container.getBeanManager()
sounds nice is not a
shortcut for<br>
> CDI.current().getBm()
otherwise it looks like
duplication to me.<br>
><br>
> Can we make container
not contextual - dont think
so? If so it makes sense<br>
> otherwise I fear it
doesnt add much.<br>
><br>
> Le 26 févr. 2015 16:19,
"Jozef Hartinger" <<a
moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>>
a écrit :<br>
>><br>
>> I like the
initialize + close()
combination and the
try-with-resources<br>
>> usage.<br>
>> What looks weird to
me is that at line one you
obtain a container handle:<br>
>><br>
>> try (CDIContainer
container =
CDIContainer.newCDIContai...<br>
>>
CDI.current().getBeanManager()
...<br>
>><br>
>> and then at line
two you call a static method
to perform a container<br>
>> lookup :-/<br>
>><br>
>> An API that allows
you to use the container
handle you already got is
way<br>
>> better IMO, e.g.:<br>
>><br>
>> try (CDIContainer
container =
CDIContainer.newCDIContai...<br>
>>
container.getBeanManager()<br>
>><br>
>> If
CDIContainer.newCDIContainer()
returns an CDI instance or
its subclass,<br>
>> we get this easily.<br>
>><br>
>> On 02/26/2015 08:58
AM, Romain Manni-Bucau
wrote:<br>
>>><br>
>>> Hi guys<br>
>>><br>
>>> why note
keeping it simple?<br>
>>><br>
>>> try
(CDIContainer container =
CDIContainer.newCDIContainer(/*
optional<br>
>>> map to
configure vendor features
*/)) {<br>
>>>
CDI.current().getBeanManager()....<br>
>>> }<br>
>>><br>
>>> Not sure the
point having initialize() +
having shutdown = close<br>
>>> really makes
the API more fluent and
modern IMO.<br>
>>><br>
>>> Also to be
fully SE I guess provider()
method would be needed even
if<br>
>>> optional (SPI
usage by default):<br>
>>><br>
>>> try
(CDIContainer container =<br>
>>><br>
>>>
CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer())<br>
>>> {<br>
>>>
CDI.current().getBeanManager()....<br>
>>> }<br>
>>><br>
>>> Finally I think
having a kind of getInstance
shortcut could be a plus for<br>
>>> SE:<br>
>>><br>
>>> try
(CDIContainer container =
CDIContainer.newCDIContainer())
{<br>
>>>
container.newInstance(MyAppRunner.class
/* optional qualifiers */<br>
>>> ).run(args);<br>
>>> }<br>
>>><br>
>>> Using container
to get an instance would
create the instance and bind<br>
>>> it to the
container lifecycle (mainly
for predestroy) avoiding
this<br>
>>> boilerplate
code in all main which will
surely only be used to
launch<br>
>>> a soft.<br>
>>><br>
>>> wdyt?<br>
>>><br>
>>><br>
>>><br>
>>> Romain
Manni-Bucau<br>
>>> @rmannibucau<br>
>>> <a
moz-do-not-send="true"
href="http://www.tomitribe.com/"
target="_blank">http://www.tomitribe.com</a><br>
>>> <a
moz-do-not-send="true"
href="http://rmannibucau.wordpress.com/"
target="_blank">http://rmannibucau.wordpress.com</a><br>
>>> <a
moz-do-not-send="true"
href="https://github.com/rmannibucau"
target="_blank">https://github.com/rmannibucau</a><br>
>>><br>
>>><br>
>>> 2015-02-26 8:32
GMT+01:00 Jozef Hartinger
<<a
moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>>:<br>
>>>><br>
>>>> Comments
inline<br>
>>>><br>
>>>> On
02/25/2015 05:53 PM, John D.
Ament wrote:<br>
>>>><br>
>>>> Sorry
Jozef, your email fell into
the pits of google inbox's
"smart<br>
>>>> sorting"<br>
>>>> features.<br>
>>>><br>
>>>> On Thu, Feb
12, 2015 at 3:18 AM Jozef
Hartinger <<a
moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi
John, comments inline:<br>
>>>>><br>
>>>>><br>
>>>>> On
02/11/2015 06:02 PM, John D.
Ament wrote:<br>
>>>>><br>
>>>>> Jozef,<br>
>>>>><br>
>>>>> Most of
what you see there is taken
from the original doc, since<br>
>>>>>
everyone<br>
>>>>> seemed
to be in agreement. I think
the map is just a safeguard
in case<br>
>>>>> of<br>
>>>>>
additional boot options
available in some
implementations (e.g. I
think<br>
>>>>>
OWB/OpenEJB have some
options.. currently OpenEJB
supports an embedded<br>
>>>>> CDI<br>
>>>>> boot
mode).<br>
>>>>><br>
>>>>> No, I
am fine with the map. What I
am questioning is the type
of the<br>
>>>>> map.<br>
>>>>>
Usually, data structures
with a similar purpose use
Strings as their<br>
>>>>> keys.<br>
>>>>> This
applies to ServletContext
attributes,
InvocationContext data,<br>
>>>>> Servlet<br>
>>>>>
request/session attributes
and others. I am therefore
wondering whether<br>
>>>>> there
is a usecase for the
proposed unbound key
signature or not.<br>
>>>><br>
>>>><br>
>>>> I think
that's more of a
placeholder, I was assuming
it would be<br>
>>>>
Map<String,Object>
once we clarify everything.<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> We
spoke a few times about
BeanManager vs CDI.
BeanManager was<br>
>>>>>
preferable<br>
>>>>> since
there's no easy way to get
the the instance, CDI is
easier to get<br>
>>>>> and<br>
>>>>> more
aligned with how you would
get it. Usually people
expect the<br>
>>>>>
BeanManager to be injected
or available via JNDI,
neither would be the<br>
>>>>> case<br>
>>>>> here.<br>
>>>>><br>
>>>>> If CDI
2.0 targets Java SE then
this container
initialization API will<br>
>>>>> become
something that ordinary
application developers use
to start/stop<br>
>>>>> CDI<br>
>>>>> in
their applications. It
therefore cannot be
considered an SPI but<br>
>>>>> instead<br>
>>>>> should
be something easy to use. On
the other hand, BeanManager
is<br>
>>>>>
definitely an SPI. It is
used in extension,
frameworks and generally<br>
>>>>> for<br>
>>>>>
integration. Not much by
applications directly.
Therefore, I don't see<br>
>>>>> how<br>
>>>>> the
container bootstrap API and
BeanManager fit together.
IMO the<br>
>>>>>
bootstrap<br>
>>>>> API
should expose something that
makes common tasks
(obtaining a<br>
>>>>>
contextual<br>
>>>>>
reference and firing and
event) easy, which the CDI
class does.<br>
>>>>><br>
>>>>> Plus do
not forget that BeanManager
can be obtained easily using<br>
>>>>>
CDI.getBeanManager().<br>
>>>><br>
>>>><br>
>>>> I'm not
disagreeing. There's a few
things I'd consider:<br>
>>>><br>
>>>> - Is this
mostly for new apps or
existing? If existing, it's
probably<br>
>>>> using<br>
>>>> some
internal API, if new it can
use whatever API we give.<br>
>>>> - I don't
want to return void, we
should give some kind of
reference<br>
>>>> into<br>
>>>> the
container when we're done
booting.<br>
>>>><br>
>>>> Agreed, we
should not be returning
void.<br>
>>>><br>
>>>> - CDI is a
one step retrievable
reference, where as
BeanManager is a two<br>
>>>> step
reference. With that said,
BeanManager makes more sense
to return<br>
>>>> here.
Another thought could be we
invent some new class that
has both,<br>
>>>> but<br>
>>>> that's
really redundant.<br>
>>>><br>
>>>> Why do you
think BeanManager makes more
sense here? Especially given
the<br>
>>>> assumption
that application code is
going to call this
init/shutdown<br>
>>>> API, I<br>
>>>> don't see
BeanManager as making more
sense.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> Yes,
this is the container start
API. Sounds like you have
some good<br>
>>>>> ideas
for things like XML
configuration or
programmatic configuration,<br>
>>>>> both<br>
>>>>> of
which are being tracked
under separate tickets. One
idea might be<br>
>>>>> for an<br>
>>>>>
optional param in the map to
control packages to
scan/ignore, in that<br>
>>>>> map.<br>
>>>>><br>
>>>>> I am
wondering whether this
configuration should be
something optional<br>
>>>>> built
on top of the bootstrap API
or whether we should
consider making<br>
>>>>> it<br>
>>>>>
mandatory. Either way, we
cannot add the bootstrap API
to the spec<br>
>>>>> without<br>
>>>>>
explicitly defining how it
behaves. My implicit
assumption of the<br>
>>>>>
proposal<br>
>>>>> is that
the container is supposed to
scan the entire classpath
for<br>
>>>>>
explicit<br>
>>>>> or
implicit bean archives
(including e.g. rt.jar),
discover beans, fire<br>
>>>>>
extensions, etc. This
worries me as this default
behavior is far from<br>
>>>>> being<br>
>>>>>
lightweight, which CDI for
Java SE initially aimed to
be.<br>
>>>><br>
>>>><br>
>>>> Yes, the
spec must be updated to
reflect the behavior of SE
mode. I<br>
>>>> plan to<br>
>>>> get that
completely into the google
doc before opening any spec
changes<br>
>>>> in a<br>
>>>> PR.<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> We
didn't want to over load the
CDI interface. It already
does a lot.<br>
>>>>> This is
really SPI code, CDI even
though it's in the spi
package is<br>
>>>>> used in<br>
>>>>> a lot
of application code.<br>
>>>>><br>
>>>>> I would
personally prefer to have it
all in one place. Having<br>
>>>>>
CDIContainer,
CDIContainerLoader, CDI and
CDIProvider makes it more<br>
>>>>>
difficult to know when to
use what.<br>
>>>><br>
>>>><br>
>>>> The problem
is that most CDI (the
interface) operations are
against a<br>
>>>> running
container. I think we spoke
about leveraging CDIProvider
at one<br>
>>>> point (in
fact, I mistakenly called
CDIContainer CDIProvider not
even<br>
>>>> realizing
it was there). I doubt that
most app developers use it<br>
>>>> currently,<br>
>>>> there's not
even a way to get a
reference to it that I'm
aware of. It's<br>
>>>> used by the
implementor only.<br>
>>>><br>
>>>> I don't
think there's a conflict.
CDI class would still only
provide<br>
>>>> methods<br>
>>>> to be run
against a running container.
The difference is that there<br>
>>>> would be<br>
>>>> additional
static methods to get this
running container (CDI
class) to<br>
>>>> you<br>
>>>> by starting
the container.<br>
>>>><br>
>>>> Either way,
I agree that reusing
CDIProvider is a must. There
is no<br>
>>>> reason<br>
>>>> to define a
new class for the same
purpose.<br>
>>>><br>
>>>><br>
>>>> I expect
that my changes in the CDI
spec around this will state,
along<br>
>>>> the<br>
>>>> lines of:<br>
>>>><br>
>>>> To retrieve
a CDIContainer to launch, do
this:<br>
>>>><br>
>>>>
CDIContainer container =
CDIContainerLocator.getCDIContainer();<br>
>>>>
container.initialize();<br>
>>>> ... do work<br>
>>>><br>
>>>> Once you
want to shutdown the
container, do this:<br>
>>>><br>
>>>>
container.shutdown();<br>
>>>><br>
>>>> (we may
want to consider
implementing AutoCloseable,
an oversight on my<br>
>>>> part)<br>
>>>><br>
>>>> and then
later on<br>
>>>><br>
>>>> - What
happens if I call
CDIContainerLocator in an
app server<br>
>>>><br>
>>>> - It throws
an IllegalStateException.<br>
>>>><br>
>>>> - The
container provides no beans
of type CDIContainer, it is
managed<br>
>>>> outside of
the CDI container.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> John<br>
>>>>><br>
>>>>> On Wed
Feb 11 2015 at 4:21:50 AM
Jozef Hartinger <<a
moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> Hi
John, some thoughts:<br>
>>>>>><br>
>>>>>> -
instead of using BeanManager
it makes more sense to me to
return a<br>
>>>>>> CDI<br>
>>>>>>
instance, which is a more
user-friendly API (and it
also exposes<br>
>>>>>>
access to<br>
>>>>>>
BeanManager)<br>
>>>>>> -
is there a usecase for
arbitrary keys of the
"params" map or is<br>
>>>>>>
Map<String, ?>
sufficient?<br>
>>>>>> -
if we could move the
shutdown() method from
CDIContainer to the<br>
>>>>>>
actual<br>
>>>>>>
container handle that we
obtain from initialize(),
that would look<br>
>>>>>>
more<br>
>>>>>>
object-oriented<br>
>>>>>> -
what exactly is initialize()
supposed to do? Is it
supposed to start<br>
>>>>>>
scanning the entire
classpath for CDI beans?
That could be a problem<br>
>>>>>>
especially with
spring-boot-like fat jars. I
think we need an API to<br>
>>>>>>
tell<br>
>>>>>> the
container which classes /
packages to consider.
Something like<br>
>>>>>>
Guice's<br>
>>>>>>
binding API perhaps?<br>
>>>>>><br>
>>>>>> -
the proposal makes me wonder
whether retrofitting this
functionality<br>
>>>>>> to<br>
>>>>>> the
CDI class wouldn't be a
better option. It could look
like:<br>
>>>>>><br>
>>>>>> CDI
container =
CDI.initialize();<br>
>>>>>>
container.select(Foo.class).get();<br>
>>>>>>
container.shutdown();<br>
>>>>>><br>
>>>>>>
compare it to:<br>
>>>>>><br>
>>>>>>
CDIContainer container =
CDIContainerLoader.
getCDIContainer();<br>
>>>>>>
BeanManager manager =
container.initialize();<br>
>>>>>>
manager.getBeans(...);<br>
>>>>>>
container.shutdown(manager);<br>
>>>>>><br>
>>>>>><br>
>>>>>> On
02/10/2015 06:58 PM, John D.
Ament wrote:<br>
>>>>>><br>
>>>>>>
All,<br>
>>>>>><br>
>>>>>> I
have the updated API here,
and wanted to solicit any
final feedback<br>
>>>>>>
before updating the google
doc and spec pages.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> <a
moz-do-not-send="true"
href="https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c"
target="_blank">https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c</a><br>
>>>>>><br>
>>>>>> Let
me know your thoughts.<br>
>>>>>><br>
>>>>>>
Thanks,<br>
>>>>>><br>
>>>>>>
John<br>
>>>>>><br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>>
cdi-dev mailing list<br>
>>>>>> <a
moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org"
target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>>>> <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
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<br>
>>>>>> the<br>
>>>>>>
code under the Apache
License, Version 2<br>
>>>>>> (<a
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
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<br>
>>>>>>
intellectual<br>
>>>>>>
property rights inherent in
such information.<br>
>>>>>><br>
>>>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> cdi-dev
mailing list<br>
>>>> <a
moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org"
target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>> <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
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<br>
>>>> under the
Apache License, Version 2<br>
>>>> (<a
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
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<br>
>>>>
intellectual<br>
>>>> property
rights inherent in such
information.<br>
>><br>
>><br>
><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
cdi-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org"
target="_blank">cdi-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
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 moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
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.</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
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
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
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>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a class="moz-txt-link-freetext" href="http://www.apache.org/licenses/LICENSE-2.0.html">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.</pre>
</blockquote>
<br>
</body>
</html>