Re: Consistent results for CDI.current().getBeanManager()

2018-03-04 Thread Mark Struberg
+1

The 'core' object in OWB is the WebBeansContext. This contains the 1 
BeanManager for the 'application'.

The lookup is done through the Finder. By default it's basically a 
Map.
But you can change this to a custom one.

Btw CDI.current() will always give you an InjectableBeanManager which is 
basically a thin wrapper which is Serializable.

LieGrue,
strub



> Am 05.03.2018 um 06:44 schrieb Romain Manni-Bucau :
> 
> Hi John
> 
> The lookup is done depending your finder impl. By default it is by
> classloader which means, if you dont end up using the same beanmanagerimpl,
> you dont have the right tccl in different places - which has impacts as
> well.
> 
> The wrapper instance is not that important here, only the delegate one
> 
> 
> Le 5 mars 2018 02:19, "John D. Ament"  a écrit :
> 
>> Hi
>> 
>> So I'm noticing when CDI.current().getBeanManager() is called, it returns a
>> new InjectableBeanManager instance.  I have a custom OWBListener (
>> https://github.com/hammock-project/hammock/blob/master/
>> bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/
>> owb/OWBListener.java)
>> which handles the lifecycle references in the servlet container.  I don't
>> want to start the application, because its already been started by the SE
>> container so my custom version doesn't do that.
>> 
>> However, I've noticed that the underlying BeanManager is not the same as
>> the one used by the SE initialization.  Is this on purpose?  Is there
>> something special that has to be done so that the underlying
>> BeanManagerImpl on WebBeansContext.getInstance().getBeanManagerImpl()
>> returns the one created via SE?
>> 
>> John
>> 



Re: Consistent results for CDI.current().getBeanManager()

2018-03-04 Thread Romain Manni-Bucau
Hi John

The lookup is done depending your finder impl. By default it is by
classloader which means, if you dont end up using the same beanmanagerimpl,
you dont have the right tccl in different places - which has impacts as
well.

The wrapper instance is not that important here, only the delegate one


Le 5 mars 2018 02:19, "John D. Ament"  a écrit :

> Hi
>
> So I'm noticing when CDI.current().getBeanManager() is called, it returns a
> new InjectableBeanManager instance.  I have a custom OWBListener (
> https://github.com/hammock-project/hammock/blob/master/
> bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/
> owb/OWBListener.java)
> which handles the lifecycle references in the servlet container.  I don't
> want to start the application, because its already been started by the SE
> container so my custom version doesn't do that.
>
> However, I've noticed that the underlying BeanManager is not the same as
> the one used by the SE initialization.  Is this on purpose?  Is there
> something special that has to be done so that the underlying
> BeanManagerImpl on WebBeansContext.getInstance().getBeanManagerImpl()
> returns the one created via SE?
>
> John
>


Consistent results for CDI.current().getBeanManager()

2018-03-04 Thread John D. Ament
Hi

So I'm noticing when CDI.current().getBeanManager() is called, it returns a
new InjectableBeanManager instance.  I have a custom OWBListener (
https://github.com/hammock-project/hammock/blob/master/bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/owb/OWBListener.java)
which handles the lifecycle references in the servlet container.  I don't
want to start the application, because its already been started by the SE
container so my custom version doesn't do that.

However, I've noticed that the underlying BeanManager is not the same as
the one used by the SE initialization.  Is this on purpose?  Is there
something special that has to be done so that the underlying
BeanManagerImpl on WebBeansContext.getInstance().getBeanManagerImpl()
returns the one created via SE?

John