<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 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 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 class="h5"><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>