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

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(a)redhat.com&gt; wrote: I think that's more of a placeholder, I was assuming it would be Map<String,Object> once we clarify everything. 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. - 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. 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. 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 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.