Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
    • Fix Version/s: 6.0.0.M1
    • Component/s: Deployers, EJB
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 9 results 

      Description

      STLBs from the EAR's lib are deployed even if they are explicitly excluded from deployment.
      More information can be found on the related forum topic.

        Issue Links

          Activity

          Hide
          Miroslav Havram
          added a comment -

          Attached is the test case already mentioned in discusion.

          Positive case is when there will be deployd only one bean. In negative case there are deployed two of them.

          Show
          Miroslav Havram
          added a comment - Attached is the test case already mentioned in discusion. Positive case is when there will be deployd only one bean. In negative case there are deployed two of them.
          Hide
          Miroslav Havram
          added a comment -

          Correction:

          In positive case there will be deployed two beans: FirstSharedBean and SecondSharedBean.
          In negative case there will be one more deployed bean: SharedBean

          Show
          Miroslav Havram
          added a comment - Correction: In positive case there will be deployed two beans: FirstSharedBean and SecondSharedBean. In negative case there will be one more deployed bean: SharedBean
          Hide
          Ales Justin
          added a comment -

          Let's see if Jaikiran can duplicate this and drill down on the actual cause.

          Show
          Ales Justin
          added a comment - Let's see if Jaikiran can duplicate this and drill down on the actual cause.
          Hide
          jaikiran pai
          added a comment -

          I could reproduce this even in 5.1.0 AS. I see what's happening in this case although i need to do some more analysis. I'll update this JIRA or open a thread in the forum for discussion.

          Show
          jaikiran pai
          added a comment - I could reproduce this even in 5.1.0 AS. I see what's happening in this case although i need to do some more analysis. I'll update this JIRA or open a thread in the forum for discussion.
          Hide
          jaikiran pai
          added a comment -

          Its the org.jboss.deployment.OptAnnotationMetaDataDeployer which is the culprit. It's implementation of deploy (through it's superclass AnnotationMetaDataDeployer) does this :

          protected void deploy(VFSDeploymentUnit unit)
          throws DeploymentException
          {
          ...
          List<VirtualFile> classpath = unit.getClassPath();
          if(classpath == null || classpath.isEmpty())
          return;

          boolean trace = log.isTraceEnabled();
          if (trace)
          log.trace("Deploying annotations for unit: " + unit + ", classpath: " + classpath);

          try
          {
          processMetaData(unit, webMetaData, clientMetaData, classpath);

          ...

          So for the unit corresponding to the ear file (test-ear.ear), it picks up the .ear/lib/shared-ejb.jar from the unit.getClasspath() and starts creating metadata out of the annotaitons in the shared-ejb.jar since lib/shared-ejb.jar forms the classpath of the ear:

          2009-10-03 02:02:19,581 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (main) Deploying annotations for unit: AbstractVFSDeploymentContext@9405908

          {vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear/}

          , classpath: [MemoryContextHandler@25410398[path= context=vfsmemory://3j001-dizj50-g0be59bs-1-g0be5nsz-2d real=vfsmemory://3j001-dizj50-g0be59bs-1-g0be5nsz-2d], DelegatingHandler@25319602[path=test-ear.ear/lib/shared-ejbs.jar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear/lib/shared-ejbs.jar], DelegatingHandler@6213371[path=test-ear.ear context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear]]

          So effectively, the ear unit now has a JBossMetaData created and attached to it from the annotation processing on lib/shared-ejb.jar file.

          Show
          jaikiran pai
          added a comment - Its the org.jboss.deployment.OptAnnotationMetaDataDeployer which is the culprit. It's implementation of deploy (through it's superclass AnnotationMetaDataDeployer) does this : protected void deploy(VFSDeploymentUnit unit) throws DeploymentException { ... List<VirtualFile> classpath = unit.getClassPath(); if(classpath == null || classpath.isEmpty()) return; boolean trace = log.isTraceEnabled(); if (trace) log.trace("Deploying annotations for unit: " + unit + ", classpath: " + classpath); try { processMetaData(unit, webMetaData, clientMetaData, classpath); ... So for the unit corresponding to the ear file (test-ear.ear), it picks up the .ear/lib/shared-ejb.jar from the unit.getClasspath() and starts creating metadata out of the annotaitons in the shared-ejb.jar since lib/shared-ejb.jar forms the classpath of the ear: 2009-10-03 02:02:19,581 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (main) Deploying annotations for unit: AbstractVFSDeploymentContext@9405908 {vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear/} , classpath: [MemoryContextHandler@25410398 [path= context=vfsmemory://3j001-dizj50-g0be59bs-1-g0be5nsz-2d real=vfsmemory://3j001-dizj50-g0be59bs-1-g0be5nsz-2d] , DelegatingHandler@25319602 [path=test-ear.ear/lib/shared-ejbs.jar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear/lib/shared-ejbs.jar] , DelegatingHandler@6213371 [path=test-ear.ear context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/test-ear.ear] ] So effectively, the ear unit now has a JBossMetaData created and attached to it from the annotation processing on lib/shared-ejb.jar file.
          Hide
          jaikiran pai
          added a comment -

          A bit more details - The OptAnnotationMetaDataDeployer uses the AnnotationEnvironment to look for annotations on classes. The AnnotationEnvironment in the deployment unit is set by the org.jboss.deployers.vfs.plugins.annotations.FilteredAnnotationEnvironmentDeployer which does not take into account that the shared-ejbs.jar belongs to the EAR/lib folder of the unit:

          protected URL[] getUrls(VFSDeploymentUnit unit) throws Exception
          {
          List<VirtualFile> classpath = unit.getClassPath();
          if (classpath != null && classpath.isEmpty() == false)
          {
          List<URL> urls = new ArrayList<URL>();
          VirtualFile root = unit.getRoot();
          for (VirtualFile cp : classpath)

          { VirtualFile check = cp; while(check != null && check.equals(root) == false) check = check.getParent(); if (check != null) urls.add(cp.toURL()); }

          if (urls.isEmpty() == false)

          { if (log.isTraceEnabled()) log.trace("Explicit urls: " + urls); return urls.toArray(new URL[urls.size()]); }

          }
          return new URL[0];
          }

          Effectively it includes classes in that jar for annotation scanning. The Annotation environment deployer is a generic deployer and not specific to EJB3 deployments. IMO, this deployer should be aware of "library-directory" of an deployment (ex: for .ear the default library-directory is "lib"). By definition a library-directory contains only libraries and hence should not be scanned for annotations. So probably, the Annotation environment deployer needs to filter out the library-directory classes during AnnotationEnvironment creation.

          Show
          jaikiran pai
          added a comment - A bit more details - The OptAnnotationMetaDataDeployer uses the AnnotationEnvironment to look for annotations on classes. The AnnotationEnvironment in the deployment unit is set by the org.jboss.deployers.vfs.plugins.annotations.FilteredAnnotationEnvironmentDeployer which does not take into account that the shared-ejbs.jar belongs to the EAR/lib folder of the unit: protected URL[] getUrls(VFSDeploymentUnit unit) throws Exception { List<VirtualFile> classpath = unit.getClassPath(); if (classpath != null && classpath.isEmpty() == false) { List<URL> urls = new ArrayList<URL>(); VirtualFile root = unit.getRoot(); for (VirtualFile cp : classpath) { VirtualFile check = cp; while(check != null && check.equals(root) == false) check = check.getParent(); if (check != null) urls.add(cp.toURL()); } if (urls.isEmpty() == false) { if (log.isTraceEnabled()) log.trace("Explicit urls: " + urls); return urls.toArray(new URL[urls.size()]); } } return new URL [0] ; } Effectively it includes classes in that jar for annotation scanning. The Annotation environment deployer is a generic deployer and not specific to EJB3 deployments. IMO, this deployer should be aware of "library-directory" of an deployment (ex: for .ear the default library-directory is "lib"). By definition a library-directory contains only libraries and hence should not be scanned for annotations. So probably, the Annotation environment deployer needs to filter out the library-directory classes during AnnotationEnvironment creation.
          Hide
          Ales Justin
          added a comment -

          >> So probably, the Annotation environment deployer needs to filter out the library-directory classes during AnnotationEnvironment creation.

          This should already be the case with EarLibExcludeDeployer - see metadata-deployer-jboss-beans.xml.
          We just need to see why this doesn't kick in.

          Show
          Ales Justin
          added a comment - >> So probably, the Annotation environment deployer needs to filter out the library-directory classes during AnnotationEnvironment creation. This should already be the case with EarLibExcludeDeployer - see metadata-deployer-jboss-beans.xml. We just need to see why this doesn't kick in.
          Hide
          Ales Justin
          added a comment -

          Fixed EarLibExcludeDeployer$UrlExcludeResourceFilter in 5_x branch.

          Show
          Ales Justin
          added a comment - Fixed EarLibExcludeDeployer$UrlExcludeResourceFilter in 5_x branch.

            People

            • Assignee:
              Ales Justin
              Reporter:
              Miroslav Havram
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: