You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Mark Struberg (Commented) (JIRA)" <ji...@apache.org> on 2012/01/01 20:19:30 UTC

[jira] [Commented] (GERONIMO-6005) Unclear how big a cdi context is for an ear

    [ https://issues.apache.org/jira/browse/GERONIMO-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178218#comment-13178218 ] 

Mark Struberg commented on GERONIMO-6005:
-----------------------------------------

I actually don't understand the term 'context' in this regard. I can only guess that you are referring to the problem that @ApplicationScoped might be underspecified. There is currently an open CID issue
https://issues.jboss.org/browse/CDI-129

Please note that CDI-18 is also related to this issue. The currently specified BDA ('Bean Archive') behaviour is not usable at all and even JBoss, Glassfish and WebLogic do _not_ implement it as strict as the spec states (1 JAR == 1 BDA) but relaxed the restrictions a bit (but different on each server). I'm sure I don't need to say that this is seriously broken ...

So far my (long) discussions with Pete seems to come to the following conclusion (discussions not yet finished): We need to think hard about re-introducing the 'hierarchic' BeanManager as it has been in the Spec shortly before the spec got finished. 

The BeanManager hierarchy setup would depend on the situation in the container, most likely 1:1 with the ClassLoader Hierarchy. 

Means 1 BeanManager for the EAR would scan all the shared ear/lib ejb-jar.xml JAR files. Each WebApp would additionally get it's own BeanManager which would only manage it's own Bean<T> and delegates to the shared Ear-BeanManager.

 This is needed due to how each javax.enterprise.context.spi.Context works internally. Each Context (e.g. a Context for @EnterpriseApplicationScoped) has a Map<Contextual<T>, T> and Map<Contextual<T>, CreationalContext<T>>. Thus for storing @EntrepriseApplicationScoped contextual instances, the Bean<T> (note: Bean<T> extends Contextual<T>) must be equal for each webapp. 

This is a pretty complicated area and neither JBoss nor Oracle managed to do this right yet...
http://markmail.org/message/cu4enktyxpiqkda2
                
> Unclear how big a cdi context is for an ear
> -------------------------------------------
>
>                 Key: GERONIMO-6005
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6005
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: general
>    Affects Versions: 3.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: 3.0
>
>         Attachments: share-owb-context.diff
>
>
> The cdi spec and pete muir are a bit unclear on how many web beans contexts there are for an ear.  At the moment the behavior is ridiculous: the ejb module sets one up using the openejb lifecycle (good) and then the web module sets one up for the same classes using the web lifecycle (bad).  At least until we understand what is supposed to happen and have separate bundles for each module the best solution (IMO) is to have a single web beans context for the entire ear, set up by openejb. This involves a slight change in the existing sharing logic.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira