<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi John, comments inline:<br>
<br>
<div class="moz-cite-prefix">On 02/11/2015 06:02 PM, John D. Ament
wrote:<br>
</div>
<blockquote
cite="mid:CAOqetn8mY5nyZEai6gAmw+h95Jc3itp7CUTgqG4ztYpnTGXRcw@mail.gmail.com"
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>
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.<br>
<blockquote
cite="mid:CAOqetn8mY5nyZEai6gAmw+h95Jc3itp7CUTgqG4ztYpnTGXRcw@mail.gmail.com"
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>
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().<br>
<blockquote
cite="mid:CAOqetn8mY5nyZEai6gAmw+h95Jc3itp7CUTgqG4ztYpnTGXRcw@mail.gmail.com"
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>
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.<br>
<blockquote
cite="mid:CAOqetn8mY5nyZEai6gAmw+h95Jc3itp7CUTgqG4ztYpnTGXRcw@mail.gmail.com"
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>
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.<br>
<blockquote
cite="mid:CAOqetn8mY5nyZEai6gAmw+h95Jc3itp7CUTgqG4ztYpnTGXRcw@mail.gmail.com"
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">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>
</body>
</html>