[jboss-as7-dev] [EE7/JPA 2.1] Question about accessing the CDI BeanManager for a component on AS7 or later...

[Pete Muir]

I talked to Scott and Steve on IRC, and we don't see a scoping problem here. There may be an issue around how the BeanManager is obtained, but that is beyond my knowledge of Weld/AS7 integration.

On 22 Aug 2012, at 16:51, Scott Marlow wrote:

> On 08/22/2012 11:32 AM, Pete Muir wrote:
>> A BeanManager is typically scoped to a Java EE module in JBoss AS AIUI.So you would be safer looking it up per component.
> 
> How does that relate to creating the EntityManagerFactory that is used with many different deployed components?  Is the same BeanManager instance expected to be used across the separate components?
> 
> When we deploy the application, for each persistence unit in the persistence.xml, we will create a EntityManagerFactory via PersistenceProvider.createContainerEntityManagerFactory().  During deployment, I don't think that I can lookup the BeanManager from JNDI, if that is what you meant.  If a separate BeanManager instance is expected to be bound to each components "java:comp/BeanManager", than we might have a mapping issue with the JPA 2.1 spec requirements.
> 
> Text from JPA 2.1 section 9.1:
> 
> "
> If the containing archive of the persistence unit is a bean archive, a BeanManager instance must be made available by the container. The container is responsible for passing this BeanManager instance via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used must be the standard property name javax.persistence.bean.manager.
> "
> 
> 
>> 
>> On 22 Aug 2012, at 16:10, Scott Marlow wrote:
>> 
>>> On 08/22/2012 10:17 AM, Scott Marlow wrote:
>>>> On 08/22/2012 10:01 AM, Steve Ebersole wrote:
>>>>> Do you at least know if a BeanManager needs to be passed?  If so, I do
>>>> 
>>>> There is a separate deployer that detects that beans.xml is present and
>>>> that a BeanManager will be available.  I could make the JPA deployer
>>>> become aware of this knowledge.
>>>> 
>>>>> not actually use the BeanManager instance until much later (second phase
>>>>> in our new vernacular); so an option if you do actually know whether you
>>>>> need to pass the BeanManager or not  would be to pass a BeanManager
>>>>> proxy that does the lookup on demand.
>>>> 
>>>> I don't think the proxy could expect to use a jndi lookup of
>>>> "java:comp/BeanManager", so not sure that the proxy would help.
>>> 
>>> What is the scope of the BeanManager instance that we associate with each component?  Do we have a separate BeanManager instance per component or per application deployment?  Or do we have a global BeanManager instance that we use for all deployments?
>>> 
>>>> 
>>>>> 
>>>>> On Wed 22 Aug 2012 08:49:23 AM CDT, Scott Marlow wrote:
>>>>>> I would like to give feedback to the JPA 2.1 EG, on the entity
>>>>>> listener enhancement to support CDI.  If the deployment archive that
>>>>>> contains the persistence unit, is a bean archive, the BeanManager
>>>>>> needs to be passed in as a property when creating the persistence unit
>>>>>> service.  The persistence provider will use the BeanManager to create
>>>>>> instances of the entity listener classes, do injection and trigger
>>>>>> lifecycle methods.
>>>>>> 
>>>>>> Currently, the only way to get the CDI BeanManager in AS7, is doing a
>>>>>> "java:comp/BeanManager" lookup (not helpful during deployment) or via
>>>>>> the BeanManagerService.  I tried to have the PersistenceUnitService
>>>>>> depend on the BeanManagerService, but couldn't start the
>>>>>> PersistenceUnitService  service (got a
>>>>>> "org.jboss.msc.service.CircularDependencyException: Service jboss-as
>>>>>> has a circular dependency" http://pastie.org/4565684).
>>>>>> 
>>>>>> I'll also need to get access to the BeanManager earlier than the
>>>>>> install phase.  I need to pass the BeanManager as a property to the
>>>>>> PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo,
>>>>>> 
>>>>>> Map) invocation which might occur early (if class transformers will
>>>>>> rewrite application classes before they are loaded).
>>>>>> 
>>>>>> I could avoid having the PU service depend on the BeanManagerService
>>>>>> if I instead arrange for the PU service to get the BeanManager from
>>>>>> the deployment unit (if available).  However, if the
>>>>>> BeanManagerService is stopped, the pu service wouldn't be stopped if
>>>>>> we have a direct reference to the BeanManager.  So, this (deployment
>>>>>> unit) hack sounds less than ideal.
>>>>>> 
>>>>>> Git branch
>>>>>> https://github.com/scottmarlow/jboss-as/tree/seven_jpa2_1_BeanManager
>>>>>> integrates with the latest Hibernate master branch (Hibernate needs to
>>>>>> be built locally) and has the currently broken BeanManager access code
>>>>>> (gets the CircularDependencyException during deployment).
>>>>>> 
>>>>>> Scott
>>>>> 
>>>>> --
>>>>> steve at hibernate.org
>>>>> http://hibernate.org
>>>> 
>>>> 
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> 
>>> 
>>> 
>> 
> 
>