[cdi-dev] Feedback - CDI bootstrap API (CDI-26)
Jozef Hartinger
jharting at redhat.com
Thu Feb 26 02:32:48 EST 2015
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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150226/bd600171/attachment-0001.html
More information about the cdi-dev
mailing list