Geronimo
  1. Geronimo
  2. GERONIMO-6005

Unclear how big a cdi context is for an ear

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0.0
    • Component/s: general
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        David Jencks added a comment -

        Here's how to share the context. Will apply it soon unless someone applies it first.

        Show
        David Jencks added a comment - Here's how to share the context. Will apply it soon unless someone applies it first.
        Hide
        Forrest Xia added a comment -

        Is it still a valid improvement for 3.0-beta and trunk code stream? Please help review and update this jira's status. thanks!

        Show
        Forrest Xia added a comment - Is it still a valid improvement for 3.0-beta and trunk code stream? Please help review and update this jira's status. thanks!
        Hide
        David Jencks added a comment -

        We have a cdi context per ear. I think the cdi 1.1 spec is going to clarify what is actually expected.

        Show
        David Jencks added a comment - We have a cdi context per ear. I think the cdi 1.1 spec is going to clarify what is actually expected.
        Hide
        Mark Struberg added a comment -

        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

        Show
        Mark Struberg added a comment - 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

          People

          • Assignee:
            David Jencks
            Reporter:
            David Jencks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development