<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
You can already do:<br>
<br>
static void run(@Observes @Initialized(ApplicationScoped.class)
Object event, InjectAnythingElseINeedHere object) {<br>
}<br>
<br>
<div class="moz-cite-prefix">On 03/04/2015 10:12 AM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote
cite="mid:CACLE=7PWvcEoOdXji5jQWCfE53GOB-FEzUL-ytPgjECKwusWnQ@mail.gmail.com"
type="cite">
<div dir="ltr">@Jozef: yes but without having to programmatically
use anything: "keep it smooth"
<div><br>
</div>
<div>Alternative and maybe cleaner would be to support boot
class in Container API:</div>
<div><br>
</div>
<div>public class MyMain {</div>
<div> @Inject SuperService service;</div>
<div><br>
</div>
<div> @Start</div>
<div> public void run() { ...}</div>
<div>}</div>
<div><br>
</div>
<div>and in the real main:</div>
<div><br>
</div>
<div><span style="font-size:12.8000001907349px">try
(CDIContainer container = CDIContainer.Builder.withBooter(</span>MyMain.class)<span
style="font-size:12.8000001907349px">.newCDIContainer(/</span><span
style="font-size:12.8000001907349px">* optional</span></div>
<div><span style="font-size:12.8000001907349px">map to configure
vendor features */)) {</span><br
style="font-size:12.8000001907349px">
<span style="font-size:12.8000001907349px"> // wait</span><br
style="font-size:12.8000001907349px">
<span style="font-size:12.8000001907349px">}</span><br>
</div>
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">PS: if we have
@Startup no need of anything then</span></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 moz-do-not-send="true"
href="https://twitter.com/rmannibucau"
target="_blank">@rmannibucau</a> | <a
moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">Blog</a> | <a
moz-do-not-send="true"
href="https://github.com/rmannibucau"
target="_blank">Github</a> | <a
moz-do-not-send="true"
href="https://www.linkedin.com/in/rmannibucau"
target="_blank">LinkedIn</a> | <a
moz-do-not-send="true"
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:06 GMT+01:00 Jozef
Hartinger <span dir="ltr"><<a moz-do-not-send="true"
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"> What exactly is the
static inject supposed to do? <br>
Would that be the same as
c.select(MyMain.class).get().doWork()?
<div>
<div class="h5"><br>
<br>
<div>On 02/28/2015 10:11 PM, Romain Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<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 moz-do-not-send="true"
href="mailto:john.d.ament@gmail.com"
target="_blank">john.d.ament@gmail.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">
<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
moz-do-not-send="true"
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 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-27 8:05 GMT+01:00 Jozef
Hartinger <<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 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>
>>>><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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
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<br>
>>>>>> 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<br>
>>>>>> intellectual<br>
>>>>>> property rights
inherent in such information.<br>
>>>>>><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<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<br>
>>>> intellectual<br>
>>>> property rights
inherent in such information.<br>
>><br>
>><br>
><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>