[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures
Flavia Rainone
flavia.rainone at jboss.com
Wed Jan 27 09:18:43 EST 2010
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.
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.
I just don't know how to fix it, because it looks like allowsReparse()
implementation is hardcoded "return false". Any pointers on how this
could be configured differently is appreciated, if that is the right way
to fix it, that is ;-).
On 01/27/2010 09:10 AM, Kabir Khan wrote:
> 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-testSuite-sun16/498/testReport/org.jboss.test.aop.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<brian.stansberry at redhat.com>
>>>> 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
--
Flavia Rainone | JBoss Core Developer
M: (+55) (+11) 8122-5466
YIM/MSNIM: flaviarnn
More information about the jboss-development
mailing list