[cdi-dev] Feedback - CDI bootstrap API (CDI-26)

Jozef Hartinger jharting at redhat.com
Wed Mar 4 04:06:51 EST 2015


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/45cad730/attachment-0001.html 


More information about the cdi-dev mailing list