glassfish
  1. glassfish
  2. GLASSFISH-16181

Deployment error when local interfaces are referenced from remote EJB when EAR contains client application

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: ejb_container
    • Labels:
      None
    • Environment:

      JDK 1.6.0_24 64 bit, Linux 64 bit

      Description

      Consider following case:
      1. Create EAR application with EJB module and client application module.
      2. EJB module should have an EJB with only local interface and an EJB with remote interface only
      3. Reference local EJB interface (injection) from the EJB with only remote interface
      4. Try to deploy application using GlassFish administration console

      Result:
      Error similar to: Error occurred during deployment: Exception while deploying the app [InjectionProblemTestCase] : Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal. Please see server.log for more details.

      Additional info:
      The same EJB module can be deployed without problems when package doesn't contain client application.
      I am attaching a test case. It is a NetBeans project: sources and precompiled EAR.

        Activity

        Hide
        marina vatkina added a comment -

        Tim, Please check why ACC looks for any of the EJB refs if the acc-client doesn't reference any...

        Show
        marina vatkina added a comment - Tim, Please check why ACC looks for any of the EJB refs if the acc-client doesn't reference any...
        Hide
        marina vatkina added a comment -

        The stack trace of the exception:

        [#|2011-03-11T15:37:32.163-0800|SEVERE|glassfish3.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=64;_ThreadName=Thread-1;|Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal
        java.lang.RuntimeException: Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal
        at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:737)
        at com.sun.enterprise.deployment.ApplicationClientDescriptor.visit(ApplicationClientDescriptor.java:667)
        at com.sun.enterprise.deployment.Application.visit(Application.java:1791)
        at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:808)
        at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277)
        at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
        at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171)
        at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:827)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:769)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:380)

        Show
        marina vatkina added a comment - The stack trace of the exception: [#|2011-03-11T15:37:32.163-0800|SEVERE|glassfish3.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=64;_ThreadName=Thread-1;|Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal java.lang.RuntimeException: Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:737) at com.sun.enterprise.deployment.ApplicationClientDescriptor.visit(ApplicationClientDescriptor.java:667) at com.sun.enterprise.deployment.Application.visit(Application.java:1791) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:808) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277) at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93) at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:827) at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:769) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:380)
        Hide
        Tim Quinn added a comment - - edited

        First, the ACC is not at all involved in this. The problem occurs during deployment, not at runtime.

        Second, the problem might be in EJBHandler (see lengthy stack trace below). For every @EJB-annotated EJB, the EJBHandler#getEjbReferenceDescriptors method looks in each ResourceContainerContext for an EJB ref for the current EJB. The problem could be that if it finds no ejb ref in that context it adds one. In this example, the app client does not actually refer to the EJB but this logic makes it look as though it does. Then, later, the validator complains (correctly) that the app client will not be able to access the local EJB which is nested inside the remote one.

        Should this logic be more selective and not add such a reference if the context is an app client one and the bean being processed is local?

        Because this is directly related to the EJB container's processing of the EJB anno I am transferring this issue to the EJB team.

        "Grizzly(1)"
        com.sun.enterprise.deployment.ApplicationClientDescriptor.addEjbReferenceDescriptor(ApplicationClientDescriptor.java:229)
        com.sun.enterprise.deployment.annotation.context.ResourceContainerContextImpl.addEjbReferenceDescriptor(ResourceContainerContextImpl.java:75)
        org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.getEjbReferenceDescriptors(EJBHandler.java:235)
        org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processEJB(EJBHandler.java:190)
        org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processAnnotation(EJBHandler.java:109)
        com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.processAnnotation(AbstractResourceHandler.java:142)
        org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
        org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
        org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
        org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:271)
        org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:199)
        org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
        com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606)
        com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
        com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432)
        com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408)
        com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383)
        com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246)
        com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255)
        com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:649)
        com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:258)
        com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
        org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:173)
        org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
        com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
        com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
        com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
        com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
        org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:388)
        com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
        com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
        com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1069)
        com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
        com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1249)
        com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1237)
        com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:473)
        com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:226)
        org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:189)
        com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
        com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
        org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
        org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
        org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
        org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
        org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
        org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
        org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
        org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
        org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
        org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
        org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
        org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
        org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
        org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
        org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
        org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
        java.lang.Thread.run(Thread.java:680)

        Show
        Tim Quinn added a comment - - edited First, the ACC is not at all involved in this. The problem occurs during deployment, not at runtime. Second, the problem might be in EJBHandler (see lengthy stack trace below). For every @EJB-annotated EJB, the EJBHandler#getEjbReferenceDescriptors method looks in each ResourceContainerContext for an EJB ref for the current EJB. The problem could be that if it finds no ejb ref in that context it adds one. In this example, the app client does not actually refer to the EJB but this logic makes it look as though it does. Then, later, the validator complains (correctly) that the app client will not be able to access the local EJB which is nested inside the remote one. Should this logic be more selective and not add such a reference if the context is an app client one and the bean being processed is local? Because this is directly related to the EJB container's processing of the EJB anno I am transferring this issue to the EJB team. "Grizzly(1)" com.sun.enterprise.deployment.ApplicationClientDescriptor.addEjbReferenceDescriptor(ApplicationClientDescriptor.java:229) com.sun.enterprise.deployment.annotation.context.ResourceContainerContextImpl.addEjbReferenceDescriptor(ResourceContainerContextImpl.java:75) org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.getEjbReferenceDescriptors(EJBHandler.java:235) org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processEJB(EJBHandler.java:190) org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processAnnotation(EJBHandler.java:109) com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.processAnnotation(AbstractResourceHandler.java:142) org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344) org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375) org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289) org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:271) org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:199) org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134) com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606) com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445) com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432) com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408) com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383) com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246) com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255) com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:649) com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:258) com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240) org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:173) org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93) com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828) com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770) com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368) com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:388) com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1069) com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98) com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1249) com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1237) com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:473) com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:226) org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:189) com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113) com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236) org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162) org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160) org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95) org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444) org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364) org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290) org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133) org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76) org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63) org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823) org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488) java.lang.Thread.run(Thread.java:680)
        Hide
        marina vatkina added a comment -

        Needs more work to solve, but it didn't work on 3.0 either

        Show
        marina vatkina added a comment - Needs more work to solve, but it didn't work on 3.0 either
        Hide
        Cheng Fang added a comment -

        The problem is NetBeans generates an incorrect MANIFEST.MF for appclient jar, with an extra Class-Path entry:

        Manifest-Version: 1.0
        Ant-Version: Apache Ant 1.8.1
        Created-By: 1.6.0_24-b07 (Sun Microsystems Inc.)
        X-COMMENT: Main-Class will be added automatically by build
        Main-Class: injectionproblemtestcase.Main
        Class-Path: InjectionProblemTestCase-ejb.jar

        As a result all the @EJB annotations in the ejb jar file are also processed by appclient.

        After deleting Class-Path entry and manually packaging the ear, it deploys fine.

        The correct way of packaging is to include only the EJB interface classes, exception classes, etc, but not the bean classes into appclient jar. You can also package all those classes shared between ejb module and appclient module into a EAR lib jar, such as

        EAR/lib/app-shared.jar
        EAR/ejb.jar
        EAR/appclient.jar

        Show
        Cheng Fang added a comment - The problem is NetBeans generates an incorrect MANIFEST.MF for appclient jar, with an extra Class-Path entry: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.8.1 Created-By: 1.6.0_24-b07 (Sun Microsystems Inc.) X-COMMENT: Main-Class will be added automatically by build Main-Class: injectionproblemtestcase.Main Class-Path: InjectionProblemTestCase-ejb.jar As a result all the @EJB annotations in the ejb jar file are also processed by appclient. After deleting Class-Path entry and manually packaging the ear, it deploys fine. The correct way of packaging is to include only the EJB interface classes, exception classes, etc, but not the bean classes into appclient jar. You can also package all those classes shared between ejb module and appclient module into a EAR lib jar, such as EAR/lib/app-shared.jar EAR/ejb.jar EAR/appclient.jar

          People

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

            Dates

            • Created:
              Updated:
              Resolved: