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