<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
My point is that from the application perspective, the user obtains
one container handle for eventual shutdown (CDIContainer) and then
looks up a different container handle (CDI) that they can use for
real work (lookup / event dispatch / etc.) It would be cleaner if
the container gave away a single handle that can do all of that.<br>
<br>
<div class="moz-cite-prefix">On 02/26/2015 05:42 PM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote
cite="mid:CACLE=7OwW=vqyMVbebfiniPXG2_N=_UxuNYx2KUoLdRtykK89Q@mail.gmail.com"
type="cite">
<p dir="ltr">Not sure I get how a CDI instance can help.</p>
<p dir="ltr">But container.getBeanManager() sounds nice is not a
shortcut for CDI.current().getBm() otherwise it looks like
duplication to me.</p>
<p dir="ltr">Can we make container not contextual - dont think so?
If so it makes sense otherwise I fear it doesnt add much.</p>
<div class="gmail_quote">Le 26 févr. 2015 16:19, "Jozef Hartinger"
<<a moz-do-not-send="true" href="mailto:jharting@redhat.com">jharting@redhat.com</a>>
a écrit :<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I like the
initialize + close() combination and the try-with-resources
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 lookup :-/<br>
<br>
An API that allows you to use the container handle you already
got is way 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, we get this easily.<br>
<br>
On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
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 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>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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 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>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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 everyone<br>
seemed to be in agreement. I think the map is just a
safeguard in case of<br>
additional boot options available in some
implementations (e.g. I think<br>
OWB/OpenEJB have some options.. currently OpenEJB
supports an embedded CDI<br>
boot mode).<br>
<br>
No, I am fine with the map. What I am questioning is the
type of the map.<br>
Usually, data structures with a similar purpose use
Strings as their keys.<br>
This applies to ServletContext attributes,
InvocationContext data, 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>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
We spoke a few times about BeanManager vs CDI.
BeanManager was preferable<br>
since there's no easy way to get the the instance, CDI
is easier to get 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 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 CDI<br>
in their applications. It therefore cannot be considered
an SPI but 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 for<br>
integration. Not much by applications directly.
Therefore, I don't see how<br>
the container bootstrap API and BeanManager fit
together. IMO the bootstrap<br>
API should expose something that makes common tasks
(obtaining a 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>
</blockquote>
<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 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 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, 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 API, I<br>
don't see BeanManager as making more sense.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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, both<br>
of which are being tracked under separate tickets. One
idea might be for an<br>
optional param in the map to control packages to
scan/ignore, in that 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 it<br>
mandatory. Either way, we cannot add the bootstrap API
to the spec without<br>
explicitly defining how it behaves. My implicit
assumption of the proposal<br>
is that the container is supposed to scan the entire
classpath for 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 being<br>
lightweight, which CDI for Java SE initially aimed to
be.<br>
</blockquote>
<br>
Yes, the spec must be updated to reflect the behavior of
SE mode. I plan to<br>
get that completely into the google doc before opening any
spec changes in a<br>
PR.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 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>
</blockquote>
<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 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 methods<br>
to be run against a running container. The difference is
that there would be<br>
additional static methods to get this running container
(CDI class) to you<br>
by starting the container.<br>
<br>
Either way, I agree that reusing CDIProvider is a must.
There is no 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 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>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi John, some thoughts:<br>
<br>
- instead of using BeanManager it makes more sense to
me to return a CDI<br>
instance, which is a more user-friendly API (and it
also exposes 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 actual<br>
container handle that we obtain from initialize(),
that would look 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 tell<br>
the container which classes / packages to consider.
Something like Guice's<br>
binding API perhaps?<br>
<br>
- the proposal makes me wonder whether retrofitting
this functionality 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>
<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 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 intellectual<br>
property rights inherent in such information.<br>
<br>
<br>
</blockquote>
</blockquote>
<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 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 intellectual<br>
property rights inherent in such information.<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>