[cdi-dev] Feedback - CDI bootstrap API (CDI-26)
Jozef Hartinger
jharting at redhat.com
Wed Mar 4 07:43:30 EST 2015
The only argument I found supporting a strict separation of those two
APIs is that it makes it easier to control when a user should or should
not use boot (i.e. it should not be used in EE for example).
That's a good argument. It's not however necessarily only achieved by
two separate interfaces but can be as well be achieved with a subclass, e.g:
- CDI for runtime operations only
- StartedCDI extends CDI (or CDIContainer or whatever - the name does
not matter at this point) for runtime operations + shutdown.
Normally, CDI is available only. The boot API however would return
StartedCDI thus allowing a user to shutdown what they started.
On 03/04/2015 12:24 PM, John D. Ament wrote:
> This is actually based on what we discussed in one of the EG meetings
>
> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html
>
> John
>
> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger <jharting at redhat.com
> <mailto:jharting at redhat.com>> wrote:
>
> Well it's nowhere given that we must have two separate interfaces
> for this. We can combine the start/stop API with the existing one
> to provide an application with a single reference representing the
> CDI container.
>
>
> On 02/28/2015 07:05 PM, John D. Ament wrote:
>> 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/97afe5fb/attachment-0001.html
More information about the cdi-dev
mailing list