<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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.<br>
<br>
<div class="moz-cite-prefix">On 03/04/2015 02:04 PM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote
cite="mid:CACLE=7OWqXw++-xN8rQBHyQ7oFN9UHT6Z0GUaXnUoSzVz-WXBg@mail.gmail.com"
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 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 13:59 GMT+01:00 Jozef
Hartinger <span dir="ltr"><<a moz-do-not-send="true"
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 class="h5"><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 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 13:43
GMT+01:00 Jozef Hartinger <span dir="ltr"><<a
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
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>
<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>
</body>
</html>