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/2c362161e18dd521f8e83c27151ddad46...
Let me know your thoughts.
Thanks,
John
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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.