<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Comments inline<br>
<br>
<div class="moz-cite-prefix">On 02/25/2015 05:53 PM, John D. Ament
wrote:<br>
</div>
<blockquote
cite="mid:CAOqetn_avwn0WLvAc0NMm72LVcVBJEsYOJBBQBDzqdRbiJ+jQA@mail.gmail.com"
type="cite">
<div dir="ltr">Sorry Jozef, your email fell into the pits of
google inbox's "smart sorting" features.<br>
<br>
<div class="gmail_quote">On Thu, Feb 12, 2015 at 3:18 AM Jozef
Hartinger <<a moz-do-not-send="true"
href="mailto:jharting@redhat.com">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"> Hi John, comments
inline:</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 02/11/2015 06:02 PM, John D. Ament wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Jozef,
<div><br>
</div>
<div>Most of what you see there is taken from the
original doc, since everyone seemed to be in
agreement. I think the map is just a safeguard in
case of additional boot options available in some
implementations (e.g. I think OWB/OpenEJB have some
options.. currently OpenEJB supports an embedded CDI
boot mode).</div>
</div>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF"> No, I am fine with
the map. What I am questioning is the type of the map.
Usually, data structures with a similar purpose use
Strings as their keys. This applies to ServletContext
attributes, InvocationContext data, Servlet
request/session attributes and others. I am therefore
wondering whether there is a usecase for the proposed
unbound key signature or not.</div>
</blockquote>
<div><br>
</div>
<div>I think that's more of a placeholder, I was assuming it
would be Map<String,Object> once we clarify
everything.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>We spoke a few times about BeanManager vs CDI.
BeanManager was preferable since there's no easy way
to get the the instance, CDI is easier to get and
more aligned with how you would get it. Usually
people expect the BeanManager to be injected or
available via JNDI, neither would be the case here.</div>
</div>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF"> If CDI 2.0 targets
Java SE then this container initialization API will become
something that ordinary application developers use to
start/stop CDI in their applications. It therefore cannot
be considered an SPI but instead should be something easy
to use. On the other hand, BeanManager is definitely an
SPI. It is used in extension, frameworks and generally for
integration. Not much by applications directly. Therefore,
I don't see how the container bootstrap API and
BeanManager fit together. IMO the bootstrap API should
expose something that makes common tasks (obtaining a
contextual reference and firing and event) easy, which the
CDI class does.<br>
<br>
Plus do not forget that BeanManager can be obtained easily
using CDI.getBeanManager().</div>
</blockquote>
<div><br>
</div>
<div>I'm not disagreeing. There's a few things I'd consider:</div>
<div><br>
</div>
<div>- Is this mostly for new apps or existing? If existing,
it's probably using some internal API, if new it can use
whatever API we give.</div>
<div>- I don't want to return void, we should give some kind
of reference into the container when we're done booting.</div>
</div>
</div>
</blockquote>
Agreed, we should not be returning void.<br>
<blockquote
cite="mid:CAOqetn_avwn0WLvAc0NMm72LVcVBJEsYOJBBQBDzqdRbiJ+jQA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>- CDI is a one step retrievable reference, where as
BeanManager is a two step reference. With that said,
BeanManager makes more sense to return here. Another
thought could be we invent some new class that has both, but
that's really redundant.</div>
</div>
</div>
</blockquote>
Why do you think BeanManager makes more sense here? Especially given
the assumption that application code is going to call this
init/shutdown API, I don't see BeanManager as making more sense.<br>
<blockquote
cite="mid:CAOqetn_avwn0WLvAc0NMm72LVcVBJEsYOJBBQBDzqdRbiJ+jQA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Yes, this is the container start API. Sounds
like you have some good ideas for things like XML
configuration or programmatic configuration, both of
which are being tracked under separate tickets. One
idea might be for an optional param in the map to
control packages to scan/ignore, in that map.</div>
</div>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF"> I am wondering
whether this configuration should be something optional
built on top of the bootstrap API or whether we should
consider making it mandatory. Either way, we cannot add
the bootstrap API to the spec without explicitly defining
how it behaves. My implicit assumption of the proposal is
that the container is supposed to scan the entire
classpath for explicit or implicit bean archives
(including e.g. rt.jar), discover beans, fire extensions,
etc. This worries me as this default behavior is far from
being lightweight, which CDI for Java SE initially aimed
to be.</div>
</blockquote>
<div><br>
</div>
<div>Yes, the spec must be updated to reflect the behavior of
SE mode. I plan to get that completely into the google doc
before opening any spec changes in a PR.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>We didn't want to over load the CDI interface.
It already does a lot. This is really SPI code, CDI
even though it's in the spi package is used in a lot
of application code.</div>
</div>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF"> I would personally
prefer to have it all in one place. Having CDIContainer,
CDIContainerLoader, CDI and CDIProvider makes it more
difficult to know when to use what.</div>
</blockquote>
<div><br>
</div>
<div>The problem is that most CDI (the interface) operations
are against a running container. I think we spoke about
leveraging CDIProvider at one point (in fact, I mistakenly
called CDIContainer CDIProvider not even realizing it was
there). I doubt that most app developers use it currently,
there's not even a way to get a reference to it that I'm
aware of. It's used by the implementor only.</div>
</div>
</div>
</blockquote>
I don't think there's a conflict. CDI class would still only provide
methods to be run against a running container. The difference is
that there would be additional static methods to get this running
container (CDI class) to you by starting the container.<br>
<br>
Either way, I agree that reusing CDIProvider is a must. There is no
reason to define a new class for the same purpose.<br>
<blockquote
cite="mid:CAOqetn_avwn0WLvAc0NMm72LVcVBJEsYOJBBQBDzqdRbiJ+jQA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I expect that my changes in the CDI spec around this will
state, along the lines of:</div>
<div><br>
</div>
<div>To retrieve a CDIContainer to launch, do this:</div>
<div><br>
</div>
<div>CDIContainer container =
CDIContainerLocator.getCDIContainer();</div>
<div>container.initialize();</div>
<div>... do work</div>
<div><br>
</div>
<div>Once you want to shutdown the container, do this:</div>
<div><br>
</div>
<div>container.shutdown();</div>
<div><br>
</div>
<div>(we may want to consider implementing AutoCloseable, an
oversight on my part)</div>
<div><br>
</div>
<div>and then later on</div>
<div><br>
</div>
<div>- What happens if I call CDIContainerLocator in an app
server</div>
<div><br>
</div>
<div>- It throws an IllegalStateException.</div>
<div><br>
</div>
<div>- The container provides no beans of type CDIContainer,
it is managed outside of the CDI container.</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">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"
onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jharting@redhat.com&cc=&bcc=&su=&body=','_blank');return
false;">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"> Hi John,
some thoughts:<br>
<br>
- instead of using BeanManager it makes more
sense to me to return a CDI instance, which is
a more user-friendly API (and it also exposes
access to BeanManager)<br>
- is there a usecase for arbitrary keys of the
"params" map or is Map<String, ?>
sufficient?<br>
- if we could move the shutdown() method from
CDIContainer to the actual container handle
that we obtain from initialize(), that would
look more object-oriented<br>
- what exactly is initialize() supposed to do?
Is it supposed to start scanning the entire
classpath for CDI beans? That could be a
problem especially with spring-boot-like fat
jars. I think we need an API to tell the
container which classes / packages to
consider. Something like Guice's binding API
perhaps?<br>
<br>
- the proposal makes me wonder whether
retrofitting this functionality to 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);</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 02/10/2015 06:58 PM, John D. Ament
wrote:<br>
</div>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">All,
<div><br>
</div>
<div>I have the updated API here, and
wanted to solicit any final feedback
before updating the google doc and spec
pages.</div>
<div><br>
</div>
<div><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>
</div>
<div><br>
</div>
<div>Let me know your thoughts.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>John</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<pre>_______________________________________________
cdi-dev mailing list
<a moz-do-not-send="true" href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a>
<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>
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">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>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>