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@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.