<div dir="ltr">Hmm CDI supposes the container is running so a container being a CDI is weird IMO - even if I get the big shortcut you want to introduce which makes sense?<div><br></div><div>+1 to hide <span style="font-size:12.8000001907349px">CDIContainerLoader</span></div></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 10:33 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">
I am wondering if we need to expose both CDIContainer and
CDIContainerLoader to the user. Could we instead follow what CDI
does where CDI is the only class exposed and CDIProvider is a
not-exposed SPI? Also, given that CDIProvider is kind of an SPI what
about reusing it as a provider of CDIContainer also?<br>
<br>
Another though: What about changing the signature to something like:<br>
<br>
public class CDIContainer extends CDI<Object> implements
AutoCloseable<span class="HOEnZb"><font color="#888888"><br>
<br>
Jozef</font></span><div><div class="h5"><br>
<br>
<div>On 03/01/2015 03:13 PM, John D. Ament
wrote:<br>
</div>
<blockquote type="cite">
<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 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 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 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>
</div>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">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 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.</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">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 code under the Apache License, Version 2 (<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 provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br></div>