glassfish
  1. glassfish
  2. GLASSFISH-18251

multiple ejb implementations of same interface not allowed in the same ear

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Works as designed
    • Affects Version/s: v2.1, 3.1.1_b12
    • Fix Version/s: None
    • Component/s: ejb_container
    • Labels:
      None

      Description

      If I have two implementations of the same remote interface in the same ear, then injection (like, into another bean located in the same ear) doesn't work and thus deployment fails:

      "... because there are 2 ejbs in the application with interface ..."

      This comes despite one of the beans is annotated with a given mappedName so there's no naming collision. If I have another app, for example a war, using this interface with injection then the default named instance is found which is correct. However, if I put this same war into the ear containing the interface/beans then the above message appears again.

      I suspect that the given mappedName-s are not reachable in jndi until the application is effectively deployed so the deployment uses another mechanism to check these constraints. But I tried to specify the "name" attribute as well which I think should work in this case but it doesn't.

      I'm not sure this is a bug but I haven't found anything related in the specs. If multiple implementations of an interface are allowed, then they should work the same way if the war is in the ear or deployed separately.

        Activity

        Hide
        Hong Zhang added a comment -

        assign to cheng for initial evaluation on this

        Show
        Hong Zhang added a comment - assign to cheng for initial evaluation on this
        Hide
        Cheng Fang added a comment -

        Having multiple implementations of the same business interface should work, regardless of the packaging.

        You can change
        @EJB NewRemote bean;
        to:
        @EJB(beanName="NewBean1")
        NewRemote bean;
        when packaging all in the same EAR.

        Or change to with all packaging scheme:
        @EJB(lookup=<portable jndi name found in server.log>)
        NewRemote bean;

        Show
        Cheng Fang added a comment - Having multiple implementations of the same business interface should work, regardless of the packaging. You can change @EJB NewRemote bean; to: @EJB(beanName="NewBean1") NewRemote bean; when packaging all in the same EAR. Or change to with all packaging scheme: @EJB(lookup=<portable jndi name found in server.log>) NewRemote bean;
        Hide
        Cheng Fang added a comment - - edited

        When all components are contained in the same EAR, resolving ejb-ref follows a different path than if they are packaged separately. In the former case, the ejb-ref can be resolved by inspecting contained components, without checking ejb-ref's jndi-name. In the latter, the server has to check ejb-ref's jndi-name. Since your app didn't specify a jndi-name for the ejb-ref (corresponding to your @EJB), the default GlassFish-specific global jndi-name is used (EjbBundleValidator 705)

        For some apps, this default is convenient; for others, may cause surprise. But I don't think we can change this behavior now. So the best practice is to explicitly tell the server what the target EJB is (as I described in previous comment).

        There is also an option to disable GlassFish-specific global jndi name:
        http://docs.oracle.com/cd/E18930_01/html/821-2418/beanx.html

        With this option, your apps will also behave consistantly.

        Show
        Cheng Fang added a comment - - edited When all components are contained in the same EAR, resolving ejb-ref follows a different path than if they are packaged separately. In the former case, the ejb-ref can be resolved by inspecting contained components, without checking ejb-ref's jndi-name. In the latter, the server has to check ejb-ref's jndi-name. Since your app didn't specify a jndi-name for the ejb-ref (corresponding to your @EJB), the default GlassFish-specific global jndi-name is used (EjbBundleValidator 705) For some apps, this default is convenient; for others, may cause surprise. But I don't think we can change this behavior now. So the best practice is to explicitly tell the server what the target EJB is (as I described in previous comment). There is also an option to disable GlassFish-specific global jndi name: http://docs.oracle.com/cd/E18930_01/html/821-2418/beanx.html With this option, your apps will also behave consistantly.
        Hide
        mangrove added a comment - - edited

        I use the beanName attribute when I want to reach the bean which is annotated by mappedName. A consistent behavior would be that if I don't specify beanName then the default (non-named) bean instance is found in either packaging case.

        Show
        mangrove added a comment - - edited I use the beanName attribute when I want to reach the bean which is annotated by mappedName. A consistent behavior would be that if I don't specify beanName then the default (non-named) bean instance is found in either packaging case.

          People

          • Assignee:
            Cheng Fang
            Reporter:
            mangrove
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: