The AOP deployer has AopMetaDataDeployerOutput.class as an output, so I added that to the WarAnnotationMetaDataDeployer as an input. Is that the right way? On 26 Jan 2010, at 18:39, Kabir Khan wrote: > Flavia and I are debugging the scoped AOP test failures in AS and have found something odd going on when deploying an ear with a war with classes. Basically WarAnnotationMetaDataDeployer loads all the classes in the war [1] before the AOPDeploymentAopMetaDataDeployer has the chance to add the bindings to the aspect manager [2]. This means that the classes in the war are loaded before the bindings are added, so they do not get woven. The deployers are in the same deployer stage POST_CLASSLOADER, what is the best way to change their orders around? > > [1] > Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 69 in SuperClassesFirstWeavingStrategy)) > SuperClassesFirstWeavingStrategy.translate(AspectManager, String, ClassLoader, byte[]) line: 69 > ScopedVFSClassLoaderDomain(AspectManager).translate(String, ClassLoader, byte[]) line: 1071 > ScopedVFSClassLoaderDomain(AspectManager).transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015 > AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, ProtectionDomain, byte[]) line: 87 > AOPTransformer.transform(ClassLoader, String, Class<?>, ProtectionDomain, byte[]) line: 75 > TransformerManager.transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 169 > InstrumentationImpl.transform(ClassLoader, String, Class, ProtectionDomain, byte[], boolean) line: 365 > ClassLoader.defineClass1(String, byte[], int, int, ProtectionDomain, String) line: not available [native method] > BaseClassLoader(ClassLoader).defineClass(String, byte[], int, int, ProtectionDomain) line: 698 > BaseClassLoader.access$200(BaseClassLoader, String, byte[], int, int, ProtectionDomain) line: 64 > BaseClassLoader$2.run() line: 577 > BaseClassLoader$2.run() line: 537 > AccessController.doPrivileged(PrivilegedAction<T>, AccessControlContext) line: not available [native method] > BaseClassLoader.loadClassLocally(String, boolean) line: 535 > BaseClassLoader.loadClassLocally(String) line: 512 > FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) line: 134 > FilteredDelegateLoader.loadClass(String) line: 131 > ClassLoadingTask$ThreadTask.run() line: 455 > ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267 > ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166 > ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String, boolean) line: 265 > ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String) line: 1124 > BaseClassLoader.loadClassFromDomain(String, boolean) line: 805 > BaseClassLoader.loadClass(String, boolean) line: 445 > BaseClassLoader(ClassLoader).loadClass(String) line: 250 > AnnotatedClassFilter.accepts(VirtualFile) line: 121 > AnnotatedClassFilter.visit(VirtualFile) line: 102 > WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) line: 62 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 362 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor) line: 307 > VFS.visit(VirtualFile, VirtualFileVisitor) line: 438 > VirtualFile.visit(VirtualFileVisitor) line: 448 > WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, VirtualFile) line: 172 > WarAnnotationMetaDataDeployer.processMetaData(VFSDeploymentUnit, List<VirtualFile>) line: 146 > WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125 > WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78 > DeployerWrapper.deploy(DeploymentUnit) line: 179 > DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431 > DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319 > DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378 > AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890 > AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019 > AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251 > AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175 > AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073 > AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887 > AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602 > DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898 > MainDeployerImpl.process() line: 677 > MainDeployer.deploy(URL) line: 370 > MainDeployer.redeploy(URL) line: 277 > > > [2] > Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 146 in AspectBinding)) > AspectBinding.start() line: 146 > GeneratedMethodAccessor192.invoke(Object, Object[]) line: not available > DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 > Method.invoke(Object, Object...) line: 597 > ReflectionUtils.invoke(Method, Object, Object[]) line: 59 > ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151 > BasicMethodJoinPoint.dispatch() line: 66 > KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 257 > KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47 > KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 125 > KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 72 > StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 202 > StartStopLifecycleAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54 > StartStopLifecycleAction(InstallsAwareAction).installAction(ControllerContext) line: 42 > StartStopLifecycleAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 > StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71 > KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51 > AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378 > ScopedKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890 > ScopedKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019 > ScopedKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251 > ScopedKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175 > ScopedKernelController(AbstractController).resolveContexts(boolean) line: 1073 > AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1104 > AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 842 > AbstractKernelController(AbstractController).install(ControllerContext) line: 589 > AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy(FakeComponentUnit, BeanMetaData) line: 363 > AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100(AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, FakeComponentUnit, BeanMetaData) line: 329 > AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, AopMetaDataDeployerOutput) line: 269 > AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) line: 133 > AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, AOPDeployment) line: 46 > AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, Object) line: 36 > AOPDeploymentAopMetaDataDeployer(AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: 56 > AOPDeploymentAopMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62 > AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 55 > DeployerWrapper.deploy(DeploymentUnit) line: 179 > DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431 > DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319 > DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378 > AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890 > AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019 > AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251 > AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175 > AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073 > AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887 > AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602 > DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898 > MainDeployerImpl.process() line: 677 > MainDeployer.deploy(URL) line: 370 > MainDeployer.redeploy(URL) line: 277 > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Eh, replied few secs too late. :-) The answer is yes, but *if* you do it via xml config, as string, this is then just additional "helper" string. AOP usage is completely transparent. Sent from my iPod On 26.1.2010, at 21:39, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > Will AopMetaDataDeployerOutput always be attached? > > On 01/26/2010 02:17 PM, Kabir Khan wrote: >> The AOP deployer has AopMetaDataDeployerOutput.class as an output, >> so I added that to the WarAnnotationMetaDataDeployer as an input. >> Is that the right way? >> On 26 Jan 2010, at 18:39, Kabir Khan wrote: >> >>> Flavia and I are debugging the scoped AOP test failures in AS and >>> have found something odd going on when deploying an ear with a war >>> with classes. Basically WarAnnotationMetaDataDeployer loads all >>> the classes in the war [1] before the >>> AOPDeploymentAopMetaDataDeployer has the chance to add the >>> bindings to the aspect manager [2]. This means that the classes in >>> the war are loaded before the bindings are added, so they do not >>> get woven. The deployers are in the same deployer stage >>> POST_CLASSLOADER, what is the best way to change their orders >>> around? >>> >>> [1] >>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>> (breakpoint at line 69 in SuperClassesFirstWeavingStrategy)) >>> SuperClassesFirstWeavingStrategy.translate(AspectManager, >>> String, ClassLoader, byte[]) line: 69 >>> ScopedVFSClassLoaderDomain(AspectManager).translate(String, >>> ClassLoader, byte[]) line: 1071 >>> ScopedVFSClassLoaderDomain(AspectManager).transform >>> (ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015 >>> AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, >>> ProtectionDomain, byte[]) line: 87 >>> AOPTransformer.transform(ClassLoader, String, Class<?>, >>> ProtectionDomain, byte[]) line: 75 >>> TransformerManager.transform(ClassLoader, String, Class, >>> ProtectionDomain, byte[]) line: 169 >>> InstrumentationImpl.transform(ClassLoader, String, Class, >>> ProtectionDomain, byte[], boolean) line: 365 >>> ClassLoader.defineClass1(String, byte[], int, int, >>> ProtectionDomain, String) line: not available [native method] >>> BaseClassLoader(ClassLoader).defineClass(String, byte[], int, >>> int, ProtectionDomain) line: 698 >>> BaseClassLoader.access$200(BaseClassLoader, String, byte[], >>> int, int, ProtectionDomain) line: 64 >>> BaseClassLoader$2.run() line: 577 >>> BaseClassLoader$2.run() line: 537 >>> AccessController.doPrivileged(PrivilegedAction<T>, >>> AccessControlContext) line: not available [native method] >>> BaseClassLoader.loadClassLocally(String, boolean) line: 535 >>> BaseClassLoader.loadClassLocally(String) line: 512 >>> FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) >>> line: 134 >>> FilteredDelegateLoader.loadClass(String) line: 131 >>> ClassLoadingTask$ThreadTask.run() line: 455 >>> ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267 >>> ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166 >>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>> (BaseClassLoader, String, boolean) line: 265 >>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>> (BaseClassLoader, String) line: 1124 >>> BaseClassLoader.loadClassFromDomain(String, boolean) line: 805 >>> BaseClassLoader.loadClass(String, boolean) line: 445 >>> BaseClassLoader(ClassLoader).loadClass(String) line: 250 >>> AnnotatedClassFilter.accepts(VirtualFile) line: 121 >>> AnnotatedClassFilter.visit(VirtualFile) line: 102 >>> WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) >>> line: 62 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 362 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>> VirtualFileFilter) line: 374 >>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>> VirtualFileHandlerVisitor) line: 307 >>> VFS.visit(VirtualFile, VirtualFileVisitor) line: 438 >>> VirtualFile.visit(VirtualFileVisitor) line: 448 >>> WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, >>> VirtualFile) line: 172 >>> WarAnnotationMetaDataDeployer.processMetaData >>> (VFSDeploymentUnit, List<VirtualFile>) line: 146 >>> WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125 >>> WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78 >>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>> line: 1378 >>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>> line: 1431 >>> DeployersImpl.install(ControllerContext, ControllerState, >>> ControllerState) line: 1319 >>> DeploymentControllerContext(AbstractControllerContext).install >>> (ControllerState, ControllerState) line: 378 >>> AbstractKernelController(AbstractController).install >>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>> AbstractKernelController(AbstractController).incrementState >>> (ControllerContext, boolean) line: 1019 >>> AbstractKernelController >>> (AbstractController).executeOrIncrementStateDirectly >>> (ControllerContext, boolean) line: 1251 >>> AbstractKernelController(AbstractController).resolveContexts >>> (ControllerState, ControllerState, boolean) line: 1175 >>> AbstractKernelController(AbstractController).resolveContexts >>> (boolean) line: 1073 >>> AbstractKernelController(AbstractController).change >>> (ControllerContext, ControllerState, boolean) line: 887 >>> AbstractKernelController(AbstractController).change >>> (ControllerContext, ControllerState) line: 602 >>> DeployersImpl.process(List<DeploymentContext>, >>> List<DeploymentContext>) line: 898 >>> MainDeployerImpl.process() line: 677 >>> MainDeployer.deploy(URL) line: 370 >>> MainDeployer.redeploy(URL) line: 277 >>> >>> >>> [2] >>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>> (breakpoint at line 146 in AspectBinding)) >>> AspectBinding.start() line: 146 >>> GeneratedMethodAccessor192.invoke(Object, Object[]) line: not >>> available >>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 >>> Method.invoke(Object, Object...) line: 597 >>> ReflectionUtils.invoke(Method, Object, Object[]) line: 59 >>> ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151 >>> BasicMethodJoinPoint.dispatch() line: 66 >>> KernelControllerContextAction$JoinpointDispatchWrapper.execute >>> () line: 257 >>> KernelControllerContextAction$JoinpointDispatchWrapper >>> (ExecutionWrapper).execute(AccessControlContext) line: 47 >>> KernelControllerContextAction.dispatchExecutionWrapper >>> (KernelControllerContext, ExecutionWrapper) line: 125 >>> KernelControllerContextAction.dispatchJoinPoint >>> (KernelControllerContext, Joinpoint) line: 72 >>> StartStopLifecycleAction(LifecycleAction).installActionInternal >>> (KernelControllerContext) line: 202 >>> StartStopLifecycleAction(InstallsAwareAction).installAction >>> (KernelControllerContext) line: 54 >>> StartStopLifecycleAction(InstallsAwareAction).installAction >>> (ControllerContext) line: 42 >>> StartStopLifecycleAction >>> (SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 >>> StartStopLifecycleAction >>> (AccessControllerContextAction<S,T>).install(ControllerContext) >>> line: 71 >>> KernelControllerContextActions >>> (AbstractControllerContextActions).install(ControllerContext, >>> ControllerState, ControllerState) line: 51 >>> AbstractKernelControllerContext >>> (AbstractControllerContext).install(ControllerState, >>> ControllerState) line: 378 >>> ScopedKernelController(AbstractController).install >>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>> ScopedKernelController(AbstractController).incrementState >>> (ControllerContext, boolean) line: 1019 >>> ScopedKernelController >>> (AbstractController).executeOrIncrementStateDirectly >>> (ControllerContext, boolean) line: 1251 >>> ScopedKernelController(AbstractController).resolveContexts >>> (ControllerState, ControllerState, boolean) line: 1175 >>> ScopedKernelController(AbstractController).resolveContexts >>> (boolean) line: 1073 >>> AbstractKernelController(AbstractController).resolveContexts >>> (boolean) line: 1104 >>> AbstractKernelController(AbstractController).install >>> (ControllerContext, boolean) line: 842 >>> AbstractKernelController(AbstractController).install >>> (ControllerContext) line: 589 >>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy >>> (FakeComponentUnit, BeanMetaData) line: 363 >>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100 >>> (AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, >>> FakeComponentUnit, BeanMetaData) line: 329 >>> AOPDeploymentAopMetaDataDeployer >>> (AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, >>> AopMetaDataDeployerOutput) line: 269 >>> AOPDeploymentAopMetaDataDeployer >>> (AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) >>> line: 133 >>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>> AOPDeployment) line: 46 >>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>> Object) line: 36 >>> AOPDeploymentAopMetaDataDeployer >>> (AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: >>> 56 >>> AOPDeploymentAopMetaDataDeployer >>> (AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) >>> line: 62 >>> AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy >>> (DeploymentUnit) line: 55 >>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>> line: 1378 >>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>> line: 1431 >>> DeployersImpl.install(ControllerContext, ControllerState, >>> ControllerState) line: 1319 >>> DeploymentControllerContext(AbstractControllerContext).install >>> (ControllerState, ControllerState) line: 378 >>> AbstractKernelController(AbstractController).install >>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>> AbstractKernelController(AbstractController).incrementState >>> (ControllerContext, boolean) line: 1019 >>> AbstractKernelController >>> (AbstractController).executeOrIncrementStateDirectly >>> (ControllerContext, boolean) line: 1251 >>> AbstractKernelController(AbstractController).resolveContexts >>> (ControllerState, ControllerState, boolean) line: 1175 >>> AbstractKernelController(AbstractController).resolveContexts >>> (boolean) line: 1073 >>> AbstractKernelController(AbstractController).change >>> (ControllerContext, ControllerState, boolean) line: 887 >>> AbstractKernelController(AbstractController).change >>> (ControllerContext, ControllerState) line: 602 >>> DeployersImpl.process(List<DeploymentContext>, >>> List<DeploymentContext>) line: 898 >>> MainDeployerImpl.process() line: 677 >>> MainDeployer.deploy(URL) line: 370 >>> MainDeployer.redeploy(URL) line: 277 >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > -- > Brian Stansberry > Lead, AS Clustering > JBoss by Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

We should still support a deployment like your aop-scoped1.sar example. These tests were passing on Jan 10[1] so for sure we didn't decide to change what we support since then. ;-) [1] http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test... On 01/26/2010 06:06 PM, Kabir Khan wrote: > Thanks, > > That works although I need to release AOP 2.1.7 before we can test that on Hudson. Or shall I do an AOP 2.1.7-Beta in the morning and upgrade AS to use that? Flavia is looking at the remaining 3 errors we get locally. She is investigating but I think the problem is in the deployers. It seems to be the something to do with > > <bean name="AOPXMLMetaDataParserDeployer" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> > <constructor> > <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter> > </constructor> > <property name="suffix">-aop.xml</property> > </bean> > > not getting triggered for jboss-aop.xml if we have this structure > > aop-scoped1.sar/ > aop-scoped1.aop/ > META-INF/ > jboss-aop.xml > META-INF/ > jboss-service.xml > > I'm not 100% sure if this is the case, but just to check do we still support nested deployments in sars? > > jboss-aop.xml gets picked up with this structure: > aop-scoped2.sar/ > jboss-aop.xml > META-INF/ > jboss-service.xml > > > On 26 Jan 2010, at 20:53, Ales Justin wrote: > >> Eh, replied few secs too late. :-) >> >> The answer is yes, but *if* you do it via xml config, as string, this >> is then just additional "helper" string. >> AOP usage is completely transparent. >> >> Sent from my iPod >> >> On 26.1.2010, at 21:39, Brian Stansberry&lt;brian.stansberry(a)redhat.com&gt; >> wrote: >> >>> Will AopMetaDataDeployerOutput always be attached? >>> >>> On 01/26/2010 02:17 PM, Kabir Khan wrote: >>>> The AOP deployer has AopMetaDataDeployerOutput.class as an output, >>>> so I added that to the WarAnnotationMetaDataDeployer as an input. >>>> Is that the right way? >>>> On 26 Jan 2010, at 18:39, Kabir Khan wrote: >>>> >>>>> Flavia and I are debugging the scoped AOP test failures in AS and >>>>> have found something odd going on when deploying an ear with a war >>>>> with classes. Basically WarAnnotationMetaDataDeployer loads all >>>>> the classes in the war [1] before the >>>>> AOPDeploymentAopMetaDataDeployer has the chance to add the >>>>> bindings to the aspect manager [2]. This means that the classes in >>>>> the war are loaded before the bindings are added, so they do not >>>>> get woven. The deployers are in the same deployer stage >>>>> POST_CLASSLOADER, what is the best way to change their orders >>>>> around? >>>>> >>>>> [1] >>>>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>>>> (breakpoint at line 69 in SuperClassesFirstWeavingStrategy)) >>>>> SuperClassesFirstWeavingStrategy.translate(AspectManager, >>>>> String, ClassLoader, byte[]) line: 69 >>>>> ScopedVFSClassLoaderDomain(AspectManager).translate(String, >>>>> ClassLoader, byte[]) line: 1071 >>>>> ScopedVFSClassLoaderDomain(AspectManager).transform >>>>> (ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015 >>>>> AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, >>>>> ProtectionDomain, byte[]) line: 87 >>>>> AOPTransformer.transform(ClassLoader, String, Class<?>, >>>>> ProtectionDomain, byte[]) line: 75 >>>>> TransformerManager.transform(ClassLoader, String, Class, >>>>> ProtectionDomain, byte[]) line: 169 >>>>> InstrumentationImpl.transform(ClassLoader, String, Class, >>>>> ProtectionDomain, byte[], boolean) line: 365 >>>>> ClassLoader.defineClass1(String, byte[], int, int, >>>>> ProtectionDomain, String) line: not available [native method] >>>>> BaseClassLoader(ClassLoader).defineClass(String, byte[], int, >>>>> int, ProtectionDomain) line: 698 >>>>> BaseClassLoader.access$200(BaseClassLoader, String, byte[], >>>>> int, int, ProtectionDomain) line: 64 >>>>> BaseClassLoader$2.run() line: 577 >>>>> BaseClassLoader$2.run() line: 537 >>>>> AccessController.doPrivileged(PrivilegedAction<T>, >>>>> AccessControlContext) line: not available [native method] >>>>> BaseClassLoader.loadClassLocally(String, boolean) line: 535 >>>>> BaseClassLoader.loadClassLocally(String) line: 512 >>>>> FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) >>>>> line: 134 >>>>> FilteredDelegateLoader.loadClass(String) line: 131 >>>>> ClassLoadingTask$ThreadTask.run() line: 455 >>>>> ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267 >>>>> ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166 >>>>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>>>> (BaseClassLoader, String, boolean) line: 265 >>>>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>>>> (BaseClassLoader, String) line: 1124 >>>>> BaseClassLoader.loadClassFromDomain(String, boolean) line: 805 >>>>> BaseClassLoader.loadClass(String, boolean) line: 445 >>>>> BaseClassLoader(ClassLoader).loadClass(String) line: 250 >>>>> AnnotatedClassFilter.accepts(VirtualFile) line: 121 >>>>> AnnotatedClassFilter.visit(VirtualFile) line: 102 >>>>> WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) >>>>> line: 62 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 362 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>> VirtualFileFilter) line: 374 >>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>> VirtualFileHandlerVisitor) line: 307 >>>>> VFS.visit(VirtualFile, VirtualFileVisitor) line: 438 >>>>> VirtualFile.visit(VirtualFileVisitor) line: 448 >>>>> WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, >>>>> VirtualFile) line: 172 >>>>> WarAnnotationMetaDataDeployer.processMetaData >>>>> (VFSDeploymentUnit, List<VirtualFile>) line: 146 >>>>> WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125 >>>>> WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78 >>>>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>>>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>> line: 1378 >>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>> line: 1431 >>>>> DeployersImpl.install(ControllerContext, ControllerState, >>>>> ControllerState) line: 1319 >>>>> DeploymentControllerContext(AbstractControllerContext).install >>>>> (ControllerState, ControllerState) line: 378 >>>>> AbstractKernelController(AbstractController).install >>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>> AbstractKernelController(AbstractController).incrementState >>>>> (ControllerContext, boolean) line: 1019 >>>>> AbstractKernelController >>>>> (AbstractController).executeOrIncrementStateDirectly >>>>> (ControllerContext, boolean) line: 1251 >>>>> AbstractKernelController(AbstractController).resolveContexts >>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>> AbstractKernelController(AbstractController).resolveContexts >>>>> (boolean) line: 1073 >>>>> AbstractKernelController(AbstractController).change >>>>> (ControllerContext, ControllerState, boolean) line: 887 >>>>> AbstractKernelController(AbstractController).change >>>>> (ControllerContext, ControllerState) line: 602 >>>>> DeployersImpl.process(List<DeploymentContext>, >>>>> List<DeploymentContext>) line: 898 >>>>> MainDeployerImpl.process() line: 677 >>>>> MainDeployer.deploy(URL) line: 370 >>>>> MainDeployer.redeploy(URL) line: 277 >>>>> >>>>> >>>>> [2] >>>>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>>>> (breakpoint at line 146 in AspectBinding)) >>>>> AspectBinding.start() line: 146 >>>>> GeneratedMethodAccessor192.invoke(Object, Object[]) line: not >>>>> available >>>>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 >>>>> Method.invoke(Object, Object...) line: 597 >>>>> ReflectionUtils.invoke(Method, Object, Object[]) line: 59 >>>>> ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151 >>>>> BasicMethodJoinPoint.dispatch() line: 66 >>>>> KernelControllerContextAction$JoinpointDispatchWrapper.execute >>>>> () line: 257 >>>>> KernelControllerContextAction$JoinpointDispatchWrapper >>>>> (ExecutionWrapper).execute(AccessControlContext) line: 47 >>>>> KernelControllerContextAction.dispatchExecutionWrapper >>>>> (KernelControllerContext, ExecutionWrapper) line: 125 >>>>> KernelControllerContextAction.dispatchJoinPoint >>>>> (KernelControllerContext, Joinpoint) line: 72 >>>>> StartStopLifecycleAction(LifecycleAction).installActionInternal >>>>> (KernelControllerContext) line: 202 >>>>> StartStopLifecycleAction(InstallsAwareAction).installAction >>>>> (KernelControllerContext) line: 54 >>>>> StartStopLifecycleAction(InstallsAwareAction).installAction >>>>> (ControllerContext) line: 42 >>>>> StartStopLifecycleAction >>>>> (SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 >>>>> StartStopLifecycleAction >>>>> (AccessControllerContextAction<S,T>).install(ControllerContext) >>>>> line: 71 >>>>> KernelControllerContextActions >>>>> (AbstractControllerContextActions).install(ControllerContext, >>>>> ControllerState, ControllerState) line: 51 >>>>> AbstractKernelControllerContext >>>>> (AbstractControllerContext).install(ControllerState, >>>>> ControllerState) line: 378 >>>>> ScopedKernelController(AbstractController).install >>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>> ScopedKernelController(AbstractController).incrementState >>>>> (ControllerContext, boolean) line: 1019 >>>>> ScopedKernelController >>>>> (AbstractController).executeOrIncrementStateDirectly >>>>> (ControllerContext, boolean) line: 1251 >>>>> ScopedKernelController(AbstractController).resolveContexts >>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>> ScopedKernelController(AbstractController).resolveContexts >>>>> (boolean) line: 1073 >>>>> AbstractKernelController(AbstractController).resolveContexts >>>>> (boolean) line: 1104 >>>>> AbstractKernelController(AbstractController).install >>>>> (ControllerContext, boolean) line: 842 >>>>> AbstractKernelController(AbstractController).install >>>>> (ControllerContext) line: 589 >>>>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy >>>>> (FakeComponentUnit, BeanMetaData) line: 363 >>>>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100 >>>>> (AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, >>>>> FakeComponentUnit, BeanMetaData) line: 329 >>>>> AOPDeploymentAopMetaDataDeployer >>>>> (AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, >>>>> AopMetaDataDeployerOutput) line: 269 >>>>> AOPDeploymentAopMetaDataDeployer >>>>> (AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) >>>>> line: 133 >>>>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>>>> AOPDeployment) line: 46 >>>>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>>>> Object) line: 36 >>>>> AOPDeploymentAopMetaDataDeployer >>>>> (AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: >>>>> 56 >>>>> AOPDeploymentAopMetaDataDeployer >>>>> (AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) >>>>> line: 62 >>>>> AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy >>>>> (DeploymentUnit) line: 55 >>>>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>>>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>> line: 1378 >>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>> line: 1431 >>>>> DeployersImpl.install(ControllerContext, ControllerState, >>>>> ControllerState) line: 1319 >>>>> DeploymentControllerContext(AbstractControllerContext).install >>>>> (ControllerState, ControllerState) line: 378 >>>>> AbstractKernelController(AbstractController).install >>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>> AbstractKernelController(AbstractController).incrementState >>>>> (ControllerContext, boolean) line: 1019 >>>>> AbstractKernelController >>>>> (AbstractController).executeOrIncrementStateDirectly >>>>> (ControllerContext, boolean) line: 1251 >>>>> AbstractKernelController(AbstractController).resolveContexts >>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>> AbstractKernelController(AbstractController).resolveContexts >>>>> (boolean) line: 1073 >>>>> AbstractKernelController(AbstractController).change >>>>> (ControllerContext, ControllerState, boolean) line: 887 >>>>> AbstractKernelController(AbstractController).change >>>>> (ControllerContext, ControllerState) line: 602 >>>>> DeployersImpl.process(List<DeploymentContext>, >>>>> List<DeploymentContext>) line: 898 >>>>> MainDeployerImpl.process() line: 677 >>>>> MainDeployer.deploy(URL) line: 370 >>>>> MainDeployer.redeploy(URL) line: 277 >>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> >>> -- >>> Brian Stansberry >>> Lead, AS Clustering >>> JBoss by Red Hat >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

This is not happening at the moment, I only get one binding added for this test and that is coming from AOP annotations on classes. I don't see SchemaResolverDeployer.parse() getting invoked for the ones from the nested aop-scoped1.aop/META-INF/jboss-aop.xml, but I see it working as expected for aop-scoped2/jboss-aop.xml. On 27 Jan 2010, at 00:19, Brian Stansberry wrote: > We should still support a deployment like your aop-scoped1.sar example. > > These tests were passing on Jan 10[1] so for sure we didn't decide to > change what we support since then. ;-) > > [1] > http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test... > > On 01/26/2010 06:06 PM, Kabir Khan wrote: > >> Thanks, >> >> That works although I need to release AOP 2.1.7 before we can test that on Hudson. Or shall I do an AOP 2.1.7-Beta in the morning and upgrade AS to use that? Flavia is looking at the remaining 3 errors we get locally. She is investigating but I think the problem is in the deployers. It seems to be the something to do with >> >> <bean name="AOPXMLMetaDataParserDeployer" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> >> <constructor> >> <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter> >> </constructor> >> <property name="suffix">-aop.xml</property> >> </bean> >> >> not getting triggered for jboss-aop.xml if we have this structure >> >> aop-scoped1.sar/ >> aop-scoped1.aop/ >> META-INF/ >> jboss-aop.xml >> META-INF/ >> jboss-service.xml >> >> I'm not 100% sure if this is the case, but just to check do we still support nested deployments in sars? >> >> jboss-aop.xml gets picked up with this structure: >> aop-scoped2.sar/ >> jboss-aop.xml >> META-INF/ >> jboss-service.xml >> >> >> On 26 Jan 2010, at 20:53, Ales Justin wrote: >> >> >>> Eh, replied few secs too late. :-) >>> >>> The answer is yes, but *if* you do it via xml config, as string, this >>> is then just additional "helper" string. >>> AOP usage is completely transparent. >>> >>> Sent from my iPod >>> >>> On 26.1.2010, at 21:39, Brian Stansberry&lt;brian.stansberry(a)redhat.com&gt; >>> wrote: >>> >>> >>>> Will AopMetaDataDeployerOutput always be attached? >>>> >>>> On 01/26/2010 02:17 PM, Kabir Khan wrote: >>>> >>>>> The AOP deployer has AopMetaDataDeployerOutput.class as an output, >>>>> so I added that to the WarAnnotationMetaDataDeployer as an input. >>>>> Is that the right way? >>>>> On 26 Jan 2010, at 18:39, Kabir Khan wrote: >>>>> >>>>> >>>>>> Flavia and I are debugging the scoped AOP test failures in AS and >>>>>> have found something odd going on when deploying an ear with a war >>>>>> with classes. Basically WarAnnotationMetaDataDeployer loads all >>>>>> the classes in the war [1] before the >>>>>> AOPDeploymentAopMetaDataDeployer has the chance to add the >>>>>> bindings to the aspect manager [2]. This means that the classes in >>>>>> the war are loaded before the bindings are added, so they do not >>>>>> get woven. The deployers are in the same deployer stage >>>>>> POST_CLASSLOADER, what is the best way to change their orders >>>>>> around? >>>>>> >>>>>> [1] >>>>>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>>>>> (breakpoint at line 69 in SuperClassesFirstWeavingStrategy)) >>>>>> SuperClassesFirstWeavingStrategy.translate(AspectManager, >>>>>> String, ClassLoader, byte[]) line: 69 >>>>>> ScopedVFSClassLoaderDomain(AspectManager).translate(String, >>>>>> ClassLoader, byte[]) line: 1071 >>>>>> ScopedVFSClassLoaderDomain(AspectManager).transform >>>>>> (ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015 >>>>>> AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, >>>>>> ProtectionDomain, byte[]) line: 87 >>>>>> AOPTransformer.transform(ClassLoader, String, Class<?>, >>>>>> ProtectionDomain, byte[]) line: 75 >>>>>> TransformerManager.transform(ClassLoader, String, Class, >>>>>> ProtectionDomain, byte[]) line: 169 >>>>>> InstrumentationImpl.transform(ClassLoader, String, Class, >>>>>> ProtectionDomain, byte[], boolean) line: 365 >>>>>> ClassLoader.defineClass1(String, byte[], int, int, >>>>>> ProtectionDomain, String) line: not available [native method] >>>>>> BaseClassLoader(ClassLoader).defineClass(String, byte[], int, >>>>>> int, ProtectionDomain) line: 698 >>>>>> BaseClassLoader.access$200(BaseClassLoader, String, byte[], >>>>>> int, int, ProtectionDomain) line: 64 >>>>>> BaseClassLoader$2.run() line: 577 >>>>>> BaseClassLoader$2.run() line: 537 >>>>>> AccessController.doPrivileged(PrivilegedAction<T>, >>>>>> AccessControlContext) line: not available [native method] >>>>>> BaseClassLoader.loadClassLocally(String, boolean) line: 535 >>>>>> BaseClassLoader.loadClassLocally(String) line: 512 >>>>>> FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) >>>>>> line: 134 >>>>>> FilteredDelegateLoader.loadClass(String) line: 131 >>>>>> ClassLoadingTask$ThreadTask.run() line: 455 >>>>>> ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267 >>>>>> ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166 >>>>>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>>>>> (BaseClassLoader, String, boolean) line: 265 >>>>>> ClassLoaderDomain(BaseClassLoaderDomain).loadClass >>>>>> (BaseClassLoader, String) line: 1124 >>>>>> BaseClassLoader.loadClassFromDomain(String, boolean) line: 805 >>>>>> BaseClassLoader.loadClass(String, boolean) line: 445 >>>>>> BaseClassLoader(ClassLoader).loadClass(String) line: 250 >>>>>> AnnotatedClassFilter.accepts(VirtualFile) line: 121 >>>>>> AnnotatedClassFilter.visit(VirtualFile) line: 102 >>>>>> WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) >>>>>> line: 62 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 362 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, >>>>>> VirtualFileFilter) line: 374 >>>>>> FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, >>>>>> VirtualFileHandlerVisitor) line: 307 >>>>>> VFS.visit(VirtualFile, VirtualFileVisitor) line: 438 >>>>>> VirtualFile.visit(VirtualFileVisitor) line: 448 >>>>>> WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, >>>>>> VirtualFile) line: 172 >>>>>> WarAnnotationMetaDataDeployer.processMetaData >>>>>> (VFSDeploymentUnit, List<VirtualFile>) line: 146 >>>>>> WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125 >>>>>> WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78 >>>>>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>>>>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>>> line: 1378 >>>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>>> line: 1431 >>>>>> DeployersImpl.install(ControllerContext, ControllerState, >>>>>> ControllerState) line: 1319 >>>>>> DeploymentControllerContext(AbstractControllerContext).install >>>>>> (ControllerState, ControllerState) line: 378 >>>>>> AbstractKernelController(AbstractController).install >>>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>>> AbstractKernelController(AbstractController).incrementState >>>>>> (ControllerContext, boolean) line: 1019 >>>>>> AbstractKernelController >>>>>> (AbstractController).executeOrIncrementStateDirectly >>>>>> (ControllerContext, boolean) line: 1251 >>>>>> AbstractKernelController(AbstractController).resolveContexts >>>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>>> AbstractKernelController(AbstractController).resolveContexts >>>>>> (boolean) line: 1073 >>>>>> AbstractKernelController(AbstractController).change >>>>>> (ControllerContext, ControllerState, boolean) line: 887 >>>>>> AbstractKernelController(AbstractController).change >>>>>> (ControllerContext, ControllerState) line: 602 >>>>>> DeployersImpl.process(List<DeploymentContext>, >>>>>> List<DeploymentContext>) line: 898 >>>>>> MainDeployerImpl.process() line: 677 >>>>>> MainDeployer.deploy(URL) line: 370 >>>>>> MainDeployer.redeploy(URL) line: 277 >>>>>> >>>>>> >>>>>> [2] >>>>>> Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended >>>>>> (breakpoint at line 146 in AspectBinding)) >>>>>> AspectBinding.start() line: 146 >>>>>> GeneratedMethodAccessor192.invoke(Object, Object[]) line: not >>>>>> available >>>>>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 >>>>>> Method.invoke(Object, Object...) line: 597 >>>>>> ReflectionUtils.invoke(Method, Object, Object[]) line: 59 >>>>>> ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151 >>>>>> BasicMethodJoinPoint.dispatch() line: 66 >>>>>> KernelControllerContextAction$JoinpointDispatchWrapper.execute >>>>>> () line: 257 >>>>>> KernelControllerContextAction$JoinpointDispatchWrapper >>>>>> (ExecutionWrapper).execute(AccessControlContext) line: 47 >>>>>> KernelControllerContextAction.dispatchExecutionWrapper >>>>>> (KernelControllerContext, ExecutionWrapper) line: 125 >>>>>> KernelControllerContextAction.dispatchJoinPoint >>>>>> (KernelControllerContext, Joinpoint) line: 72 >>>>>> StartStopLifecycleAction(LifecycleAction).installActionInternal >>>>>> (KernelControllerContext) line: 202 >>>>>> StartStopLifecycleAction(InstallsAwareAction).installAction >>>>>> (KernelControllerContext) line: 54 >>>>>> StartStopLifecycleAction(InstallsAwareAction).installAction >>>>>> (ControllerContext) line: 42 >>>>>> StartStopLifecycleAction >>>>>> (SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 >>>>>> StartStopLifecycleAction >>>>>> (AccessControllerContextAction<S,T>).install(ControllerContext) >>>>>> line: 71 >>>>>> KernelControllerContextActions >>>>>> (AbstractControllerContextActions).install(ControllerContext, >>>>>> ControllerState, ControllerState) line: 51 >>>>>> AbstractKernelControllerContext >>>>>> (AbstractControllerContext).install(ControllerState, >>>>>> ControllerState) line: 378 >>>>>> ScopedKernelController(AbstractController).install >>>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>>> ScopedKernelController(AbstractController).incrementState >>>>>> (ControllerContext, boolean) line: 1019 >>>>>> ScopedKernelController >>>>>> (AbstractController).executeOrIncrementStateDirectly >>>>>> (ControllerContext, boolean) line: 1251 >>>>>> ScopedKernelController(AbstractController).resolveContexts >>>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>>> ScopedKernelController(AbstractController).resolveContexts >>>>>> (boolean) line: 1073 >>>>>> AbstractKernelController(AbstractController).resolveContexts >>>>>> (boolean) line: 1104 >>>>>> AbstractKernelController(AbstractController).install >>>>>> (ControllerContext, boolean) line: 842 >>>>>> AbstractKernelController(AbstractController).install >>>>>> (ControllerContext) line: 589 >>>>>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy >>>>>> (FakeComponentUnit, BeanMetaData) line: 363 >>>>>> AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100 >>>>>> (AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, >>>>>> FakeComponentUnit, BeanMetaData) line: 329 >>>>>> AOPDeploymentAopMetaDataDeployer >>>>>> (AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, >>>>>> AopMetaDataDeployerOutput) line: 269 >>>>>> AOPDeploymentAopMetaDataDeployer >>>>>> (AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) >>>>>> line: 133 >>>>>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>>>>> AOPDeployment) line: 46 >>>>>> AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, >>>>>> Object) line: 36 >>>>>> AOPDeploymentAopMetaDataDeployer >>>>>> (AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: >>>>>> 56 >>>>>> AOPDeploymentAopMetaDataDeployer >>>>>> (AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) >>>>>> line: 62 >>>>>> AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy >>>>>> (DeploymentUnit) line: 55 >>>>>> DeployerWrapper.deploy(DeploymentUnit) line: 179 >>>>>> DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 >>>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>>> line: 1378 >>>>>> DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) >>>>>> line: 1431 >>>>>> DeployersImpl.install(ControllerContext, ControllerState, >>>>>> ControllerState) line: 1319 >>>>>> DeploymentControllerContext(AbstractControllerContext).install >>>>>> (ControllerState, ControllerState) line: 378 >>>>>> AbstractKernelController(AbstractController).install >>>>>> (ControllerContext, ControllerState, ControllerState) line: 1890 >>>>>> AbstractKernelController(AbstractController).incrementState >>>>>> (ControllerContext, boolean) line: 1019 >>>>>> AbstractKernelController >>>>>> (AbstractController).executeOrIncrementStateDirectly >>>>>> (ControllerContext, boolean) line: 1251 >>>>>> AbstractKernelController(AbstractController).resolveContexts >>>>>> (ControllerState, ControllerState, boolean) line: 1175 >>>>>> AbstractKernelController(AbstractController).resolveContexts >>>>>> (boolean) line: 1073 >>>>>> AbstractKernelController(AbstractController).change >>>>>> (ControllerContext, ControllerState, boolean) line: 887 >>>>>> AbstractKernelController(AbstractController).change >>>>>> (ControllerContext, ControllerState) line: 602 >>>>>> DeployersImpl.process(List<DeploymentContext>, >>>>>> List<DeploymentContext>) line: 898 >>>>>> MainDeployerImpl.process() line: 677 >>>>>> MainDeployer.deploy(URL) line: 370 >>>>>> MainDeployer.redeploy(URL) line: 277 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Lead, AS Clustering >>>> JBoss by Red Hat >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> > > -- > Brian Stansberry > Lead, AS Clustering > JBoss by Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> I think I found out why this is happening. > > When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is triggered > to process the .aop unit, there is already a metadata previously created > for the annotated binding. Take a look at the beginning of method > AbstractParsingDeployerWithOutput.createMetaData: > protected void createMetaData(DeploymentUnit unit, Set<String> names, > String suffix, String key) throws DeploymentException > { > // First see whether it already exists > T result = getMetaData(unit, key); > if (result != null && allowsReparse() == false) > return; > > // Create it > .... > > So, result is not null (it contains the annotated binding) and > allowsReparse returns false, thus preventing the deployer from finding > META-INF/aop.xml. Where does the previous metadata come from? (OK, annotation binding, but where is this annotation binding?)

Either this deployer kicks in at the wrong stage, or you're didn't consider any metadata merging. > I compared this with the behavior of deploying aop-scopedear1.aop. This > file contains no aspect annotations and, hence, > AOPXMLMetaDataParserDeployer gets a null result at the beginning of > createMetaData and is able to find META-INF/jboss-aop.xml file. > > We are not seeing the same failure for aop-scoped2 because the aop.xml > file is outside META-INF and, for what I saw during debugging, this is > treated as a child unit. So there is no searching for > META-INF/jboss-aop.xml involved. Yes, xml/config files outside metadata locations (META-INF, ...) are treated as subdeployments. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Why does AOPAnnotationMetaDataParserDeployer have to be at PARSE stage? Kabir Khan wrote: > On 27 Jan 2010, at 14:26, Ales Justin wrote: > >>> I think I found out why this is happening. >>> >>> When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is >>> triggered to process the .aop unit, there is already a metadata >>> previously created for the annotated binding. Take a look at the >>> beginning of method AbstractParsingDeployerWithOutput.createMetaData: >>> protected void createMetaData(DeploymentUnit unit, Set<String> >>> names, String suffix, String key) throws DeploymentException >>> { >>> // First see whether it already exists >>> T result = getMetaData(unit, key); >>> if (result != null && allowsReparse() == false) >>> return; >>> >>> // Create it >>> .... >>> >>> So, result is not null (it contains the annotated binding) and >>> allowsReparse returns false, thus preventing the deployer from >>> finding META-INF/aop.xml. >> Where does the previous metadata come from? >> (OK, annotation binding, but where is this annotation binding?) > > The annotations are in classes in the .aop archive. They are parsed by > AOPAnnotationMetaDataParserDeployer which should come after the > SchemaResolverDeployer > > public class AOPAnnotationMetaDataParserDeployer extends AbstractDeployer > { > public AOPAnnotationMetaDataParserDeployer(int xmlParserOrder) > { > super.setOutput(AOPDeployment.class); > super.setStage(DeploymentStages.PARSE); > //Make this come after the AOPXMLMetaDataParserDeployer > super.setRelativeOrder(xmlParserOrder + 1); > } > > public void deploy(DeploymentUnit unit) throws DeploymentException > { > .... > AOPDeployment deployment = unit.getAttachment(AOPDeployment.class); > if (factories != null && factories.size() > 0) > { > if (deployment == null) > { > deployment = new AOPDeployment(); > unit.addAttachment(AOPDeployment.class.getName(), > deployment, AOPDeployment.class); > } > ... > } } > > deployers.xml > <bean name="AOPXMLMetaDataParserDeployer" > class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> > <constructor> > > <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter> > > </constructor> > <property name="suffix">-aop.xml</property> > </bean> > <bean name="AOPAnnotationMetaDataParserDeployer" > class="org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer"> > > <constructor> > <parameter><inject bean="AOPXMLMetaDataParserDeployer" > property="relativeOrder"/></parameter> > </constructor> > </bean> > > > >> Either this deployer kicks in at the wrong stage, >> or you're didn't consider any metadata merging. >> >>> I compared this with the behavior of deploying aop-scopedear1.aop. >>> This file contains no aspect annotations and, hence, >>> AOPXMLMetaDataParserDeployer gets a null result at the beginning of >>> createMetaData and is able to find META-INF/jboss-aop.xml file. >>> >>> We are not seeing the same failure for aop-scoped2 because the >>> aop.xml file is outside META-INF and, for what I saw during >>> debugging, this is treated as a child unit. So there is no searching >>> for META-INF/jboss-aop.xml involved. >> Yes, xml/config files outside metadata locations (META-INF, ...) are >> treated as subdeployments. >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

When modifying tomcat/src/resources/war-deployers-jboss-beans.xml I noticed that there was loads of use of relative order in the existing deployers there On 27 Jan 2010, at 15:50, Ales Justin wrote: > Looking at the code, I don't see a reason why it cannot be at POST_PARSE. > > Another thing we can notice from this issue is that deployers ordering > has changed -- it seems we (already) no longer use relative order for > ordering. > > So, be alert on similar issues, as I've already found few things related > to bad/insufficient info of inputs/outputs in deployers. > (the alt-dd issue was a result of this) > > Ales Justin wrote: >> Why does AOPAnnotationMetaDataParserDeployer have to be at PARSE stage? >> >> Kabir Khan wrote: >>> On 27 Jan 2010, at 14:26, Ales Justin wrote: >>> >>>>> I think I found out why this is happening. >>>>> >>>>> When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is >>>>> triggered to process the .aop unit, there is already a metadata >>>>> previously created for the annotated binding. Take a look at the >>>>> beginning of method AbstractParsingDeployerWithOutput.createMetaData: >>>>> protected void createMetaData(DeploymentUnit unit, Set<String> >>>>> names, String suffix, String key) throws DeploymentException >>>>> { >>>>> // First see whether it already exists >>>>> T result = getMetaData(unit, key); >>>>> if (result != null && allowsReparse() == false) >>>>> return; >>>>> >>>>> // Create it >>>>> .... >>>>> >>>>> So, result is not null (it contains the annotated binding) and >>>>> allowsReparse returns false, thus preventing the deployer from >>>>> finding META-INF/aop.xml. >>>> Where does the previous metadata come from? >>>> (OK, annotation binding, but where is this annotation binding?) >>> The annotations are in classes in the .aop archive. They are parsed by >>> AOPAnnotationMetaDataParserDeployer which should come after the >>> SchemaResolverDeployer >>> >>> public class AOPAnnotationMetaDataParserDeployer extends AbstractDeployer >>> { >>> public AOPAnnotationMetaDataParserDeployer(int xmlParserOrder) >>> { >>> super.setOutput(AOPDeployment.class); >>> super.setStage(DeploymentStages.PARSE); >>> //Make this come after the AOPXMLMetaDataParserDeployer >>> super.setRelativeOrder(xmlParserOrder + 1); >>> } >>> >>> public void deploy(DeploymentUnit unit) throws DeploymentException >>> { >>> .... >>> AOPDeployment deployment = unit.getAttachment(AOPDeployment.class); >>> if (factories != null && factories.size() > 0) >>> { >>> if (deployment == null) >>> { >>> deployment = new AOPDeployment(); >>> unit.addAttachment(AOPDeployment.class.getName(), >>> deployment, AOPDeployment.class); >>> } >>> ... >>> } } >>> >>> deployers.xml >>> <bean name="AOPXMLMetaDataParserDeployer" >>> class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> >>> <constructor> >>> >>> <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter> >>> >>> </constructor> >>> <property name="suffix">-aop.xml</property> >>> </bean> >>> <bean name="AOPAnnotationMetaDataParserDeployer" >>> class="org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer"> >>> >>> <constructor> >>> <parameter><inject bean="AOPXMLMetaDataParserDeployer" >>> property="relativeOrder"/></parameter> >>> </constructor> >>> </bean> >>> >>> >>> >>>> Either this deployer kicks in at the wrong stage, >>>> or you're didn't consider any metadata merging. >>>> >>>>> I compared this with the behavior of deploying aop-scopedear1.aop. >>>>> This file contains no aspect annotations and, hence, >>>>> AOPXMLMetaDataParserDeployer gets a null result at the beginning of >>>>> createMetaData and is able to find META-INF/jboss-aop.xml file. >>>>> >>>>> We are not seeing the same failure for aop-scoped2 because the >>>>> aop.xml file is outside META-INF and, for what I saw during >>>>> debugging, this is treated as a child unit. So there is no searching >>>>> for META-INF/jboss-aop.xml involved. >>>> Yes, xml/config files outside metadata locations (META-INF, ...) are >>>> treated as subdeployments. >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Any news on the feature additions so that I can switch to using a more optimized annotation deployer ?

Moving it to POST_PARSE fixes the three failure we were seeing, but introduces a new failure. If m2eclipse finishes updating maven dependencies before Sunday I'll try to debug why.

The aspects coming from annotations are ignored. I'm digging into it, so far I have only found that with the annotation deployer in post_parse the metadata coming from the annotations are correctly added to AOPDeployment On 27 Jan 2010, at 16:40, Ales Justin wrote: > What's this new failure? > > Kabir Khan wrote: >> Moving it to POST_PARSE fixes the three failure we were seeing, but >> introduces a new failure. If m2eclipse finishes updating maven >> dependencies before Sunday I'll try to debug why. > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Looking at the code, I don't see a reason why it cannot be at POST_PARSE. Another thing we can notice from this issue is that deployers ordering has changed -- it seems we (already) no longer use relative order for ordering.

So, be alert on similar issues, as I've already found few things related to bad/insufficient info of inputs/outputs in deployers. (the alt-dd issue was a result of this) Ales Justin wrote: > Why does AOPAnnotationMetaDataParserDeployer have to be at PARSE stage? > > Kabir Khan wrote: > >> On 27 Jan 2010, at 14:26, Ales Justin wrote: >> >> >>>> I think I found out why this is happening. >>>> >>>> When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is >>>> triggered to process the .aop unit, there is already a metadata >>>> previously created for the annotated binding. Take a look at the >>>> beginning of method AbstractParsingDeployerWithOutput.createMetaData: >>>> protected void createMetaData(DeploymentUnit unit, Set<String> >>>> names, String suffix, String key) throws DeploymentException >>>> { >>>> // First see whether it already exists >>>> T result = getMetaData(unit, key); >>>> if (result != null&& allowsReparse() == false) >>>> return; >>>> >>>> // Create it >>>> .... >>>> >>>> So, result is not null (it contains the annotated binding) and >>>> allowsReparse returns false, thus preventing the deployer from >>>> finding META-INF/aop.xml. >>>> >>> Where does the previous metadata come from? >>> (OK, annotation binding, but where is this annotation binding?) >>> >> The annotations are in classes in the .aop archive. They are parsed by >> AOPAnnotationMetaDataParserDeployer which should come after the >> SchemaResolverDeployer >> >> public class AOPAnnotationMetaDataParserDeployer extends AbstractDeployer >> { >> public AOPAnnotationMetaDataParserDeployer(int xmlParserOrder) >> { >> super.setOutput(AOPDeployment.class); >> super.setStage(DeploymentStages.PARSE); >> //Make this come after the AOPXMLMetaDataParserDeployer >> super.setRelativeOrder(xmlParserOrder + 1); >> } >> >> public void deploy(DeploymentUnit unit) throws DeploymentException >> { >> .... >> AOPDeployment deployment = unit.getAttachment(AOPDeployment.class); >> if (factories != null&& factories.size()> 0) >> { >> if (deployment == null) >> { >> deployment = new AOPDeployment(); >> unit.addAttachment(AOPDeployment.class.getName(), >> deployment, AOPDeployment.class); >> } >> ... >> } } >> >> deployers.xml >> <bean name="AOPXMLMetaDataParserDeployer" >> class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> >> <constructor> >> >> <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter> >> >> </constructor> >> <property name="suffix">-aop.xml</property> >> </bean> >> <bean name="AOPAnnotationMetaDataParserDeployer" >> class="org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer"> >> >> <constructor> >> <parameter><inject bean="AOPXMLMetaDataParserDeployer" >> property="relativeOrder"/></parameter> >> </constructor> >> </bean> >> >> >> >> >>> Either this deployer kicks in at the wrong stage, >>> or you're didn't consider any metadata merging. >>> >>> >>>> I compared this with the behavior of deploying aop-scopedear1.aop. >>>> This file contains no aspect annotations and, hence, >>>> AOPXMLMetaDataParserDeployer gets a null result at the beginning of >>>> createMetaData and is able to find META-INF/jboss-aop.xml file. >>>> >>>> We are not seeing the same failure for aop-scoped2 because the >>>> aop.xml file is outside META-INF and, for what I saw during >>>> debugging, this is treated as a child unit. So there is no searching >>>> for META-INF/jboss-aop.xml involved. >>>> >>> Yes, xml/config files outside metadata locations (META-INF, ...) are >>> treated as subdeployments. >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> On 01/27/2010 04:50 PM, Ales Justin wrote: > >> Looking at the code, I don't see a reason why it cannot be at POST_PARSE. >> >> Another thing we can notice from this issue is that deployers ordering >> has changed -- it seems we (already) no longer use relative order for >> ordering. >> >> > This is not true. > You don't know that. ;-) As DependenciesTopologicalDeployerSorter is actually currently not used,

and I have no other explanation on why that Web deployer kicked in before AOP deployer -- their relative order was an explicit order hack: AOP = Web + 1.

This could be either good or bad: * good: exposed some issues; e.g. alt-dd order * bad: it didn't expose some issues :-); e.g. we might have bad/random order We can try switching to this sort alg, doing it on a clean Hudson run would be best - to expose any changes.

_______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> On 01/27/2010 04:50 PM, Ales Justin wrote: >> Looking at the code, I don't see a reason why it cannot be at POST_PARSE. >> >> Another thing we can notice from this issue is that deployers ordering >> has changed -- it seems we (already) no longer use relative order for >> ordering. >> > This is not true. You don't know that. ;-) As DependenciesTopologicalDeployerSorter is actually currently not used, and I have no other explanation on why that Web deployer kicked in before AOP deployer -- their relative order was an explicit order hack: AOP = Web + 1.

> In case it's relevant, the EAR deployer uses relative order in the case > of strict (descriptor) ordering. Which ear deployer, as there are a few? Why does it need relative order?

Ah, I see. We're talking about different things. :-) You're talking about how we order deployments, whereas I'm talking about deployers. On Feb 1, 2010, at 10:26 PM, Jason T. Greene wrote: > Ales Justin wrote: >>> In case it's relevant, the EAR deployer uses relative order in the case >>> of strict (descriptor) ordering. >> Which ear deployer, as there are a few? >> Why does it need relative order? > EARStructure. When strict is enabled, it needs a way to specify > sequential ordering (the order as specified in application.xml). Since > everything is always sorted via a treemap, a numerical index is needed. > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

The AOP deployer has AopMetaDataDeployerOutput.class as an output, so I added that to the WarAnnotationMetaDataDeployer as an input. Is that the right way? On 26 Jan 2010, at 18:39, Kabir Khan wrote: > Flavia and I are debugging the scoped AOP test failures in AS and > have found something odd going on when deploying an ear with a war > with classes. Basically WarAnnotationMetaDataDeployer loads all the > classes in the war [1] before the AOPDeploymentAopMetaDataDeployer > has the chance to add the bindings to the aspect manager [2]. This > means that the classes in the war are loaded before the bindings > are added, so they do not get woven. The deployers are in the same > deployer stage POST_CLASSLOADER, what is the best way to change > their orders around? > > [1] > Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended > (breakpoint at line 69 in SuperClassesFirstWeavingStrategy)) > SuperClassesFirstWeavingStrategy.translate(AspectManager, > String, ClassLoader, byte[]) line: 69 > ScopedVFSClassLoaderDomain(AspectManager).translate(String, > ClassLoader, byte[]) line: 1071 > ScopedVFSClassLoaderDomain(AspectManager).transform(ClassLoader, > String, Class, ProtectionDomain, byte[]) line: 1015 > AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, > ProtectionDomain, byte[]) line: 87 > AOPTransformer.transform(ClassLoader, String, Class<?>, > ProtectionDomain, byte[]) line: 75 > TransformerManager.transform(ClassLoader, String, Class, > ProtectionDomain, byte[]) line: 169 > InstrumentationImpl.transform(ClassLoader, String, Class, > ProtectionDomain, byte[], boolean) line: 365 > ClassLoader.defineClass1(String, byte[], int, int, > ProtectionDomain, String) line: not available [native method] > BaseClassLoader(ClassLoader).defineClass(String, byte[], int, > int, ProtectionDomain) line: 698 > BaseClassLoader.access$200(BaseClassLoader, String, byte[], int, > int, ProtectionDomain) line: 64 > BaseClassLoader$2.run() line: 577 > BaseClassLoader$2.run() line: 537 > AccessController.doPrivileged(PrivilegedAction<T>, > AccessControlContext) line: not available [native method] > BaseClassLoader.loadClassLocally(String, boolean) line: 535 > BaseClassLoader.loadClassLocally(String) line: 512 > FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) > line: 134 > FilteredDelegateLoader.loadClass(String) line: 131 > ClassLoadingTask$ThreadTask.run() line: 455 > ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267 > ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166 > ClassLoaderDomain(BaseClassLoaderDomain).loadClass > (BaseClassLoader, String, boolean) line: 265 > ClassLoaderDomain(BaseClassLoaderDomain).loadClass > (BaseClassLoader, String) line: 1124 > BaseClassLoader.loadClassFromDomain(String, boolean) line: 805 > BaseClassLoader.loadClass(String, boolean) line: 445 > BaseClassLoader(ClassLoader).loadClass(String) line: 250 > AnnotatedClassFilter.accepts(VirtualFile) line: 121 > AnnotatedClassFilter.visit(VirtualFile) line: 102 > WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) > line: 62 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 362 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, > VirtualFileFilter) line: 374 > FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, > VirtualFileHandlerVisitor) line: 307 > VFS.visit(VirtualFile, VirtualFileVisitor) line: 438 > VirtualFile.visit(VirtualFileVisitor) line: 448 > WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, > VirtualFile) line: 172 > WarAnnotationMetaDataDeployer.processMetaData(VFSDeploymentUnit, > List<VirtualFile>) line: 146 > WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125 > WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78 > DeployerWrapper.deploy(DeploymentUnit) line: 179 > DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) > line: 1378 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) > line: 1431 > DeployersImpl.install(ControllerContext, ControllerState, > ControllerState) line: 1319 > DeploymentControllerContext(AbstractControllerContext).install > (ControllerState, ControllerState) line: 378 > AbstractKernelController(AbstractController).install > (ControllerContext, ControllerState, ControllerState) line: 1890 > AbstractKernelController(AbstractController).incrementState > (ControllerContext, boolean) line: 1019 > AbstractKernelController > (AbstractController).executeOrIncrementStateDirectly > (ControllerContext, boolean) line: 1251 > AbstractKernelController(AbstractController).resolveContexts > (ControllerState, ControllerState, boolean) line: 1175 > AbstractKernelController(AbstractController).resolveContexts > (boolean) line: 1073 > AbstractKernelController(AbstractController).change > (ControllerContext, ControllerState, boolean) line: 887 > AbstractKernelController(AbstractController).change > (ControllerContext, ControllerState) line: 602 > DeployersImpl.process(List<DeploymentContext>, > List<DeploymentContext>) line: 898 > MainDeployerImpl.process() line: 677 > MainDeployer.deploy(URL) line: 370 > MainDeployer.redeploy(URL) line: 277 > > > [2] > Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended > (breakpoint at line 146 in AspectBinding)) > AspectBinding.start() line: 146 > GeneratedMethodAccessor192.invoke(Object, Object[]) line: not > available > DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 > Method.invoke(Object, Object...) line: 597 > ReflectionUtils.invoke(Method, Object, Object[]) line: 59 > ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151 > BasicMethodJoinPoint.dispatch() line: 66 > KernelControllerContextAction$JoinpointDispatchWrapper.execute() > line: 257 > KernelControllerContextAction$JoinpointDispatchWrapper > (ExecutionWrapper).execute(AccessControlContext) line: 47 > KernelControllerContextAction.dispatchExecutionWrapper > (KernelControllerContext, ExecutionWrapper) line: 125 > KernelControllerContextAction.dispatchJoinPoint > (KernelControllerContext, Joinpoint) line: 72 > StartStopLifecycleAction(LifecycleAction).installActionInternal > (KernelControllerContext) line: 202 > StartStopLifecycleAction(InstallsAwareAction).installAction > (KernelControllerContext) line: 54 > StartStopLifecycleAction(InstallsAwareAction).installAction > (ControllerContext) line: 42 > StartStopLifecycleAction > (SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 > StartStopLifecycleAction > (AccessControllerContextAction<S,T>).install(ControllerContext) > line: 71 > KernelControllerContextActions > (AbstractControllerContextActions).install(ControllerContext, > ControllerState, ControllerState) line: 51 > AbstractKernelControllerContext > (AbstractControllerContext).install(ControllerState, > ControllerState) line: 378 > ScopedKernelController(AbstractController).install > (ControllerContext, ControllerState, ControllerState) line: 1890 > ScopedKernelController(AbstractController).incrementState > (ControllerContext, boolean) line: 1019 > ScopedKernelController > (AbstractController).executeOrIncrementStateDirectly > (ControllerContext, boolean) line: 1251 > ScopedKernelController(AbstractController).resolveContexts > (ControllerState, ControllerState, boolean) line: 1175 > ScopedKernelController(AbstractController).resolveContexts > (boolean) line: 1073 > AbstractKernelController(AbstractController).resolveContexts > (boolean) line: 1104 > AbstractKernelController(AbstractController).install > (ControllerContext, boolean) line: 842 > AbstractKernelController(AbstractController).install > (ControllerContext) line: 589 > AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy > (FakeComponentUnit, BeanMetaData) line: 363 > AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100 > (AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, > FakeComponentUnit, BeanMetaData) line: 329 > AOPDeploymentAopMetaDataDeployer > (AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, > AopMetaDataDeployerOutput) line: 269 > AOPDeploymentAopMetaDataDeployer > (AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) line: > 133 > AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, > AOPDeployment) line: 46 > AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, > Object) line: 36 > AOPDeploymentAopMetaDataDeployer > (AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: 56 > AOPDeploymentAopMetaDataDeployer > (AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) > line: 62 > AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy > (DeploymentUnit) line: 55 > DeployerWrapper.deploy(DeploymentUnit) line: 179 > DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) > line: 1378 > DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) > line: 1431 > DeployersImpl.install(ControllerContext, ControllerState, > ControllerState) line: 1319 > DeploymentControllerContext(AbstractControllerContext).install > (ControllerState, ControllerState) line: 378 > AbstractKernelController(AbstractController).install > (ControllerContext, ControllerState, ControllerState) line: 1890 > AbstractKernelController(AbstractController).incrementState > (ControllerContext, boolean) line: 1019 > AbstractKernelController > (AbstractController).executeOrIncrementStateDirectly > (ControllerContext, boolean) line: 1251 > AbstractKernelController(AbstractController).resolveContexts > (ControllerState, ControllerState, boolean) line: 1175 > AbstractKernelController(AbstractController).resolveContexts > (boolean) line: 1073 > AbstractKernelController(AbstractController).change > (ControllerContext, ControllerState, boolean) line: 887 > AbstractKernelController(AbstractController).change > (ControllerContext, ControllerState) line: 602 > DeployersImpl.process(List<DeploymentContext>, > List<DeploymentContext>) line: 898 > MainDeployerImpl.process() line: 677 > MainDeployer.deploy(URL) line: 370 > MainDeployer.redeploy(URL) line: 277 > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development