<div dir="ltr">Sure but since the path from main(String[]) to CDI is actually this one it can be the solution. This is not the general way to use CDI but the way to enter CDI for me, then you simply use @Inject.</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 href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a 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 15:46 GMT+01:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Sure, I am not saying Unmanaged should not be used at all. Under
given circumstances it makes sense to use Unmanaged. I however don't
think it fits as the general recommended way of using CDI in SE
because if a given class is a bean already, the managed instance
should be obtained instead of creating an unmanaged instance.<div><div class="h5"><br>
<br>
<div>On 03/04/2015 02:04 PM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Your definition seems to fit the standalone need:
libraries = not CDI based code (case of a standalone), the
runner class (Mymain) doesnt have to be a CDI bean but has to
get injections to launch the CDI code.</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<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 href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a 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 13:59 GMT+01:00 Jozef
Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> UnmanagedInstance is
provided to make it easier for libraries to perform
dependency injection on classes that are for some reason
not CDI beans. It should not be a substitute for lookup of
CDI beans. Therefore, I do not see UnmanagedInstance
fitting here.
<div>
<div><br>
<br>
<div>On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hmm
<div><br>
</div>
<div>I think one of the main point I try to push
is we have a bunch of API to do it already, if
we need yet another API to do the same we have
several choices:</div>
<div>- we love creating APIs</div>
<div>- all previous APIs are failures and should
be deprecated or fixed</div>
<div>- there is a full mismatch with embedded and
EE case (but we have existing proofs it is not
the case)</div>
<div><br>
</div>
<div>I think we should help user to not be lost
between all APIs and I strongly believe we can't
do anything on container to lookup beans
(EJBContainer#getContext was a try which is
close to it but it actually just limited user
experience compared to existing solutions).</div>
<div><br>
</div>
<div>What's the issue with UnmanagedInstance?</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<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 href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a>
| <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> |
<a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> |
<a 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 13:43
GMT+01:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> The
only argument I found supporting a strict
separation of those two APIs is that it
makes it easier to control when a user
should or should not use boot (i.e. it
should not be used in EE for example).<br>
<br>
That's a good argument. It's not however
necessarily only achieved by two separate
interfaces but can be as well be achieved
with a subclass, e.g:<br>
- CDI for runtime operations only<br>
- StartedCDI extends CDI (or CDIContainer or
whatever - the name does not matter at this
point) for runtime operations + shutdown.<br>
<br>
Normally, CDI is available only. The boot
API however would return StartedCDI thus
allowing a user to shutdown what they
started.
<div>
<div><br>
<br>
<br>
<div>On 03/04/2015 12:24 PM, John D.
Ament wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">This is actually based
on what we discussed in one of the
EG meetings
<div><br>
</div>
<div><a href="http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html" target="_blank">http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html</a></div>
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">On Wed,
Mar 4, 2015 at 4:05 AM Jozef
Hartinger <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Well it's
nowhere given that we must
have two separate interfaces
for this. We can combine the
start/stop API with the
existing one to provide an
application with a single
reference representing the
CDI container.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 02/28/2015 07:05 PM,
John D. Ament wrote:<br>
</div>
<blockquote type="cite">
<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 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 href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a 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 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 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 href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>>> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>>> <a 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 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 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 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 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 href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>>>>
<a 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 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 href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>> <a 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 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>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>