Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: 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
    • 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.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            havramm 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
            havramm 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
            havramm 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
            havramm 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
            alesj Ales Justin added a comment -

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

            Show
            alesj Ales Justin added a comment - Let's see if Jaikiran can duplicate this and drill down on the actual cause.
            Hide
            jaikiran 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 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 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 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 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 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
            alesj 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
            alesj 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
            alesj Ales Justin added a comment -

            Fixed EarLibExcludeDeployer$UrlExcludeResourceFilter in 5_x branch.

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development