[cdi-dev] Feedback - CDI bootstrap API (CDI-26)
Jozef Hartinger
jharting at redhat.com
Wed Mar 4 04:36:32 EST 2015
You can already do:
static void run(@Observes @Initialized(ApplicationScoped.class) Object
event, InjectAnythingElseINeedHere object) {
}
On 03/04/2015 10:12 AM, Romain Manni-Bucau wrote:
> @Jozef: yes but without having to programmatically use anything: "keep
> it smooth"
>
> Alternative and maybe cleaner would be to support boot class in
> Container API:
>
> public class MyMain {
> @Inject SuperService service;
>
> @Start
> public void run() { ...}
> }
>
> and in the real main:
>
> try (CDIContainer container =
> CDIContainer.Builder.withBooter(MyMain.class).newCDIContainer(/* optional
> map to configure vendor features */)) {
> // wait
> }
>
> PS: if we have @Startup no need of anything then
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-03-04 10:06 GMT+01:00 Jozef Hartinger <jharting at redhat.com
> <mailto:jharting at redhat.com>>:
>
> What exactly is the static inject supposed to do?
> Would that be the same as c.select(MyMain.class).get().doWork()?
>
>
> On 02/28/2015 10:11 PM, Romain Manni-Bucau wrote:
>>
>> Yes but not the way to get an instance. Even Unmanaged does it.
>>
>> What can be awesome is to have static inject for it:
>>
>> public class Runner {
>>
>> @Inject
>> private static MyMain main;
>>
>> public static void main(String[] arg) {
>> try (CDIContainer c = CDIContainer.newContainer()) {
>> main.doWork();
>> }
>> }
>>
>> }
>>
>> And not a single additional line :).
>>
>> Le 28 févr. 2015 19:05, "John D. Ament" <john.d.ament at gmail.com
>> <mailto:john.d.ament at gmail.com>> a écrit :
>>
>> Maybe I'm misreading, but I don't see us adding another API
>> to do the same thing here - we're introducing new functionality.
>>
>> CDIContainer/Loader on startup/shutdown of the application
>>
>> CDI for runtime usage within the application to interact with
>> the container.
>>
>> John
>>
>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau
>> <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>>
>> sure I fully agree excepted I think introducing yet
>> another API to do
>> the same thing is not good so super tempting to skip it
>> and wait for
>> feedbacks rather than introducing it eagerly.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger
>> <jharting at redhat.com <mailto:jharting at redhat.com>>:
>> > 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.
>> >
>> >
>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote:
>> >
>> > Not sure I get how a CDI instance can help.
>> >
>> > But container.getBeanManager() sounds nice is not a
>> shortcut for
>> > CDI.current().getBm() otherwise it looks like
>> duplication to me.
>> >
>> > Can we make container not contextual - dont think so?
>> If so it makes sense
>> > otherwise I fear it doesnt add much.
>> >
>> > Le 26 févr. 2015 16:19, "Jozef Hartinger"
>> <jharting at redhat.com <mailto:jharting at redhat.com>> a écrit :
>> >>
>> >> I like the initialize + close() combination and the
>> try-with-resources
>> >> usage.
>> >> What looks weird to me is that at line one you obtain
>> a container handle:
>> >>
>> >> try (CDIContainer container = CDIContainer.newCDIContai...
>> >> CDI.current().getBeanManager() ...
>> >>
>> >> and then at line two you call a static method to
>> perform a container
>> >> lookup :-/
>> >>
>> >> An API that allows you to use the container handle you
>> already got is way
>> >> better IMO, e.g.:
>> >>
>> >> try (CDIContainer container = CDIContainer.newCDIContai...
>> >> container.getBeanManager()
>> >>
>> >> If CDIContainer.newCDIContainer() returns an CDI
>> instance or its subclass,
>> >> we get this easily.
>> >>
>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote:
>> >>>
>> >>> Hi guys
>> >>>
>> >>> why note keeping it simple?
>> >>>
>> >>> try (CDIContainer container =
>> CDIContainer.newCDIContainer(/* optional
>> >>> map to configure vendor features */)) {
>> >>> CDI.current().getBeanManager()....
>> >>> }
>> >>>
>> >>> Not sure the point having initialize() + having
>> shutdown = close
>> >>> really makes the API more fluent and modern IMO.
>> >>>
>> >>> Also to be fully SE I guess provider() method would
>> be needed even if
>> >>> optional (SPI usage by default):
>> >>>
>> >>> try (CDIContainer container =
>> >>>
>> >>>
>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer())
>> >>> {
>> >>> CDI.current().getBeanManager()....
>> >>> }
>> >>>
>> >>> Finally I think having a kind of getInstance shortcut
>> could be a plus for
>> >>> SE:
>> >>>
>> >>> try (CDIContainer container =
>> CDIContainer.newCDIContainer()) {
>> >>> container.newInstance(MyAppRunner.class /* optional
>> qualifiers */
>> >>> ).run(args);
>> >>> }
>> >>>
>> >>> Using container to get an instance would create the
>> instance and bind
>> >>> it to the container lifecycle (mainly for predestroy)
>> avoiding this
>> >>> boilerplate code in all main which will surely only
>> be used to launch
>> >>> a soft.
>> >>>
>> >>> wdyt?
>> >>>
>> >>>
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau
>> >>> http://www.tomitribe.com
>> >>> http://rmannibucau.wordpress.com
>> >>> https://github.com/rmannibucau
>> >>>
>> >>>
>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger
>> <jharting at redhat.com <mailto:jharting at redhat.com>>:
>> >>>>
>> >>>> Comments inline
>> >>>>
>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote:
>> >>>>
>> >>>> Sorry Jozef, your email fell into the pits of google
>> inbox's "smart
>> >>>> sorting"
>> >>>> features.
>> >>>>
>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger
>> <jharting at redhat.com <mailto:jharting at redhat.com>>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi John, comments inline:
>> >>>>>
>> >>>>>
>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote:
>> >>>>>
>> >>>>> Jozef,
>> >>>>>
>> >>>>> 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).
>> >>>>>
>> >>>>> 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.
>> >>>>
>> >>>>
>> >>>> I think that's more of a placeholder, I was assuming
>> it would be
>> >>>> Map<String,Object> once we clarify everything.
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> Plus do not forget that BeanManager can be obtained
>> easily using
>> >>>>> CDI.getBeanManager().
>> >>>>
>> >>>>
>> >>>> I'm not disagreeing. There's a few things I'd consider:
>> >>>>
>> >>>> - 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.
>> >>>> - I don't want to return void, we should give some
>> kind of reference
>> >>>> into
>> >>>> the container when we're done booting.
>> >>>>
>> >>>> Agreed, we should not be returning void.
>> >>>>
>> >>>> - 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.
>> >>>>
>> >>>> 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.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> 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.
>> >>>>
>> >>>>
>> >>>> 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.
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> 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.
>> >>>>
>> >>>>
>> >>>> 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.
>> >>>>
>> >>>> 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.
>> >>>>
>> >>>> Either way, I agree that reusing CDIProvider is a
>> must. There is no
>> >>>> reason
>> >>>> to define a new class for the same purpose.
>> >>>>
>> >>>>
>> >>>> I expect that my changes in the CDI spec around this
>> will state, along
>> >>>> the
>> >>>> lines of:
>> >>>>
>> >>>> To retrieve a CDIContainer to launch, do this:
>> >>>>
>> >>>> CDIContainer container =
>> CDIContainerLocator.getCDIContainer();
>> >>>> container.initialize();
>> >>>> ... do work
>> >>>>
>> >>>> Once you want to shutdown the container, do this:
>> >>>>
>> >>>> container.shutdown();
>> >>>>
>> >>>> (we may want to consider implementing AutoCloseable,
>> an oversight on my
>> >>>> part)
>> >>>>
>> >>>> and then later on
>> >>>>
>> >>>> - What happens if I call CDIContainerLocator in an
>> app server
>> >>>>
>> >>>> - It throws an IllegalStateException.
>> >>>>
>> >>>> - The container provides no beans of type
>> CDIContainer, it is managed
>> >>>> outside of the CDI container.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> John
>> >>>>>
>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger
>> <jharting at redhat.com <mailto:jharting at redhat.com>>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Hi John, some thoughts:
>> >>>>>>
>> >>>>>> - 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)
>> >>>>>> - is there a usecase for arbitrary keys of the
>> "params" map or is
>> >>>>>> Map<String, ?> sufficient?
>> >>>>>> - 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
>> >>>>>> - 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?
>> >>>>>>
>> >>>>>> - the proposal makes me wonder whether
>> retrofitting this functionality
>> >>>>>> to
>> >>>>>> the CDI class wouldn't be a better option. It
>> could look like:
>> >>>>>>
>> >>>>>> CDI container = CDI.initialize();
>> >>>>>> container.select(Foo.class).get();
>> >>>>>> container.shutdown();
>> >>>>>>
>> >>>>>> compare it to:
>> >>>>>>
>> >>>>>> CDIContainer container = CDIContainerLoader.
>> getCDIContainer();
>> >>>>>> BeanManager manager = container.initialize();
>> >>>>>> manager.getBeans(...);
>> >>>>>> container.shutdown(manager);
>> >>>>>>
>> >>>>>>
>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote:
>> >>>>>>
>> >>>>>> All,
>> >>>>>>
>> >>>>>> I have the updated API here, and wanted to solicit
>> any final feedback
>> >>>>>> before updating the google doc and spec pages.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c
>> >>>>>>
>> >>>>>> Let me know your thoughts.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>> John
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> cdi-dev mailing list
>> >>>>>> cdi-dev at lists.jboss.org
>> <mailto:cdi-dev at lists.jboss.org>
>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>>>>
>> >>>>>> Note that for all code provided on this list, the
>> provider licenses
>> >>>>>> the
>> >>>>>> code under the Apache License, Version 2
>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html).
>> For all other ideas
>> >>>>>> provided on this list, the provider waives all
>> patent and other
>> >>>>>> intellectual
>> >>>>>> property rights inherent in such information.
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> cdi-dev mailing list
>> >>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>>
>> >>>> Note that for all code provided on this list, the
>> provider licenses the
>> >>>> code
>> >>>> under the Apache License, Version 2
>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html).
>> For all other ideas
>> >>>> provided on this list, the provider waives all
>> patent and other
>> >>>> intellectual
>> >>>> property rights inherent in such information.
>> >>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/4d8e300f/attachment-0001.html
More information about the cdi-dev
mailing list