AOPConstructorJoinpoint and methodHasSubInstanceMetaData

[adrian.brock]

While looking at this issue:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=139622

I noticed something funny.

These are showing up as a minor hotspot during a boot/shutdown of jboss

java.lang.Class.getMethod(Class.java:1581)
org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:146)
org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:276)
org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:160)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasSubInstanceMetaData(AOPConstructorJoinpoint.java:172)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(AOPConstructorJoinpoint.java:150)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.rootHasSubInstanceMetaData(AOPConstructorJoinpoint.java:130)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:93)
org.jboss.beans.info.plugins.AbstractBeanInfo.newInstance(AbstractBeanInfo.java:269)
org.jboss.beans.info.plugins.AbstractBeanInfo.newInstance(AbstractBeanInfo.java:263)

java.lang.Class.getMethod(Class.java:1581)
org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:146)
org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:276)
org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:160)
org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getMetaDataMethodAnnotationDependencies(AOPDependencyBuilder.java:234)
org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getMethodAnnotationDependencies(AOPDependencyBuilder.java:211) org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getAnnotationDependencies(AOPDependencyBuilder.java:154)
org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getDependencies(AOPDependencyBuilder.java:132) org.jboss.kernel.plugins.dependency.DescribeAction.uninstallActionInternal(DescribeAction.java:94)
org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)

What's funny is I'm also seeing this

java.lang.Throwable.fillInStackTrace(Throwable.java:Unknown line)
java.lang.Throwable.<init>(Throwable.java:196)
java.lang.Exception.<init>(Exception.java:41)
java.lang.NoSuchMethodException.<init>(NoSuchMethodException.java:32)
java.lang.Class.getMethod(Class.java:1581)
org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:146)
org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:276)
org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:160)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasSubInstanceMetaData(AOPConstructorJoinpoint.java:172)
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(AOPConstructorJoinpoint.java:150)

NOTE: This is just using hprof to run cpu samples,
so I'm guessing the reason for the hotspot is that it is constructing
the exception a lot.

The sampling (at 10ms intervals) caught it 5 times in the example I'm quoting from.

[kabirkhan]

I'll hazard a guess

The original MethodInfo comes from AOPConstructorJoinPoint

 private boolean rootHasMethodWithSubInstanceMetaData(MetaData metaData)
 {
 ....
 MethodInfo[] methods = info.getDeclaredMethods();
 if (methods != null)
 {
 for (MethodInfo mi : methods)
 {
 if (methodHasSubInstanceMetaData(metaData, mi))
 {
 return true;
 }
 }
 }
 ---
 }

Are the semantics of MethodInfo.getDeclaredMethods() the same as of Class.getDeclaredMethods()? In that case it would return private and protected methods, so these would get passed in to AnnotatedElementMetaDataLoader. getComponentMetaDataRetrieval() which in turn calls Class.getMethod(), which will fail on anything non-public.

 public MetaDataRetrieval getComponentMetaDataRetrieval(Signature signature)
 {
 ...
 else if (signature instanceof MethodSignature)
 {
 try
 {
 Method method = clazz.getMethod(signature.getName(), signature.getParametersTypes(clazz));
 return new AnnotatedElementMetaDataLoader(method);
 }
 catch (NoSuchMethodException e)
 {
 return null;
 }
 }
 }
 }

Changing that to use class.getDeclaredMethod() might fix this

[adrian.brock]

Are you expecting to retrieve metadata from non-public methods

If so then we need to fix AnnotatedElementMetaLoader to let you do that.

Just using getDeclaredMethod() is wrong since it wouldn't be able to
get annotations on methods from a super classes.

It looks like Ales already did this for fields with his findField() call.

[adrian.brock]

Jira Issue: https://jira.jboss.org/jira/browse/JBMDR-29

[adrian.brock]

I've fixed that, but I still seeing the problem.
I added some logging. If you replace jboss-mdr with the latest build
and enable trace for org.jboss.metadata.plugins.loader.reflection
you should see lots of

2008-07-23 19:59:07,706 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature put[java.lang.Object, java.lan
g.Object] does not exist on class org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature clear[] does not exist on clas
s org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature hash[int] does not exist on cl
ass org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature hash[java.lang.Object] does no
t exist on class org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature entrySet[] does not exist on c
lass org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature get[java.lang.Object] does not
 exist on class org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature putAll[java.util.Map] does not
 exist on class org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature size[] does not exist on class
 org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature values[] does not exist on cla
ss org.jboss.ejb3.cache.CacheFactoryRegistry
2008-07-23 19:59:07,707 DEBUG [org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader] (main) Method with signature init[] does not exist on class
 org.jboss.ejb3.cache.CacheFactoryRegistry

[kabirkhan]

Setting a breakpoint in AnnotatedElementLoader, it fails on

Method with signature get[int] does not exist on class org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect

The stacktrace is:

Thread [main] (Suspended (breakpoint at line 150 in AnnotatedElementMetaDataLoader))
 AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150
 AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276
 MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160
 AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 171
 AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 149
 AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 129
 AOPConstructorJoinpoint.dispatch() line: 92
 AbstractListMetaData(AbstractTypeMetaData).createInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 251
 AbstractListMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 292
 AbstractListMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>) line: 271
 AbstractListMetaData(AbstractCollectionMetaData).getValue(TypeInfo, ClassLoader) line: 109
 PropertyDispatchWrapper.execute() line: 87
 PropertyDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
 KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109
 ConfigureAction.dispatchSetProperty(KernelControllerContext, PropertyMetaData, boolean, BeanInfo, Object, ClassLoader) line: 109
 ConfigureAction.setAttributes(KernelControllerContext, Object, BeanInfo, BeanMetaData, boolean) line: 87
 ConfigureAction.installActionInternal(KernelControllerContext) line: 44
 ConfigureAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
 ConfigureAction(InstallsAwareAction).installAction(ControllerContext) line: 42
 ConfigureAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
 ConfigureAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
 KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51

Going back to AOPConstructorJoinPoint, the contained constructorInfo is public java.util.ArrayList(), so it is iterating over ArrayList's methods. However, looking at KernelControllerContextActions the installed bean is of type org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect:

AbstractKernelControllerContext@cd8e39{ metadata=AbstractBeanMetaData@e6750f{name=WSNativeEndpointRecordProcessorDeploymentAspect bean=org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect properties=[mbeanServer, processors, requires, provides] constructor=null autowireCandidate=true}name=WSNativeEndpointRecordProcessorDeploymentAspect target=org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect@9d0863 state=Instantiated depends=AbstractDependencyInfo@91cb98{idependOn=[AbstractDependencyItem@1de5b9{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSMBeanServerLocator whenRequired=Configured resolved=true}, AbstractDependencyItem@d4f822{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSMemoryBufferRecorder whenRequired=Configured resolved=true}, AbstractDependencyItem@ee97af{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSLogRecorder whenRequired=Configured resolved=true}] unresolved=[AbstractDependencyItem@1de5b9{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSMBeanServerLocator whenRequired=Configured resolved=true}, AbstractDependencyItem@d4f822{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSMemoryBufferRecorder whenRequired=Configured resolved=true}, AbstractDependencyItem@ee97af{name=WSNativeEndpointRecordProcessorDeploymentAspect dependsOn=WSLogRecorder whenRequired=Configured resolved=true}]}}

So it would seem that when creating the properties for the bean, it uses the MetaData for the bean, which does not contain the methods for the properties. Maybe we need to call MetaDataStack.mask() as part of ConfigureAction.setAttributes()?

[adrian.brock]

So it would seem that when creating the properties for the bean, it uses the MetaData for the bean, which does not contain the methods for the properties. Maybe we need to call MetaDataStack.mask() as part of ConfigureAction.setAttributes()?

Is that the cause or are you guessing?

Do you know where the wrong ConstructorInfo is coming from.

[kabirkhan]

BTW looking at ReflectionUtils.findMethod() it relies on exceptions:

 public static Method findMethod(Class<?> clazz, String name, Class<?>... parameterTypes)
 {
 if (clazz == null)
 return null;

 try
 {
 return clazz.getDeclaredMethod(name, parameterTypes);
 }
 catch(Exception ignored)
 {
 }
 return findMethod(clazz.getSuperclass(), name, parameterTypes);
 }

Since exceptions are expensive to create, I threw together a small benchmark

public class TestFindMethods
{

 public static void main(String[] args)
 {
 Class<?> clazz = ArrayList.class;
 //Use the name of one of the last methods from the base class, but with non-matching params
 //(The method is called java.util.AbstractCollection.retainAll(Collection<?>))
 String name = "retainAll";
 Class<?>[] params = new Class<?>[] {Integer.class};

 long get = 0;
 long iterate = 0;
 for (int i = 0 ; i < 10000000 ; i++)
 {
 long start1 = System.currentTimeMillis();
 Method m1 = getDeclaredMethod(clazz, name, params);
 get += (System.currentTimeMillis() - start1);

 long start2 = System.currentTimeMillis();
 Method m2 = iterateDeclaredMethods(clazz, name, params);
 iterate += (System.currentTimeMillis() - start2);
 }

 System.out.println("Get took " + get);
 System.out.println("Iterate took " + iterate);
 }

 private static Method getDeclaredMethod(Class clazz, String name, Class<?>[] params)
 {
 try
 {
 return clazz.getDeclaredMethod(name, params);
 }
 catch(Exception e)
 {

 }
 clazz = clazz.getSuperclass();
 if (clazz != null)
 {
 return getDeclaredMethod(clazz, name, params);
 }
 return null;
 }

 private static Method iterateDeclaredMethods(Class<?> clazz, String name, Class<?>[] params)
 {
 Method[] methods = clazz.getDeclaredMethods();
 for (int i = 0 ; i < methods.length ; i++)
 {
 if (name.equals(methods.getName()))
 {
 Class<?>[] myparams = methods.getParameterTypes();
 if (myparams.length == params.length)
 {
 for (int j = 0 ; j < myparams.length ; j++)
 {
 if (params[j] != myparams[j])
 {
 break;
 }
 return methods;
 }
 }
 }
 }
 clazz = clazz.getSuperclass();
 if (clazz != null)
 {
 return iterateDeclaredMethods(clazz, name, params);
 }
 return null;
 }
 }

Running it I get:

Get took 179658
Iterate took 112402

Of course if we get rid of the cause of not finding these methods then this becomes less relevant.

[kabirkhan]

So it would seem that when creating the properties for the bean, it uses the MetaData for the bean, which does not contain the methods for the properties. Maybe we need to call MetaDataStack.mask() as part of ConfigureAction.setAttributes()?

Is that the cause or are you guessing?

Do you know where the wrong ConstructorInfo is coming from.

I believe it is the cause, but I am not so familiar with that part of MC. Let's call it an educated guess :-) Looking at EndpointRecordProcessorDeploymentAspect, it does contain a List property called "processors". Setting a breakpoint again, different class this time, it fails for a bean of type org.jboss.ejb3.cache.CacheFactoryRegistry. This contains a property

public class CacheFactoryRegistry
{
 // Instance Members
 private Map<String, Class<? extends Ejb3CacheFactory>> factories;

 // Accessors / Mutators

 public Map<String, Class<? extends Ejb3CacheFactory>> getFactories()
 {
 return factories;
 }

 public void setFactories(Map<String, Class<? extends Ejb3CacheFactory>> factories)
 {
 this.factories = factories;
 }
...
}

The stack trace this time is

AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150
AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276
MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160
AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 171
AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 149
AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 129
AOPConstructorJoinpoint.dispatch() line: 92
AbstractMapMetaData(AbstractTypeMetaData).createInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 251
AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 292
AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>) line: 271
AbstractMapMetaData.getValue(TypeInfo, ClassLoader) line: 117
PropertyDispatchWrapper.execute() line: 87
PropertyDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109
ConfigureAction.dispatchSetProperty(KernelControllerContext, PropertyMetaData, boolean, BeanInfo, Object, ClassLoader) line: 109
ConfigureAction.setAttributes(KernelControllerContext, Object, BeanInfo, BeanMetaData, boolean) line: 87
ConfigureAction.installActionInternal(KernelControllerContext) line: 44
ConfigureAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
ConfigureAction(InstallsAwareAction).installAction(ControllerContext) line: 42
ConfigureAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
ConfigureAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348

The KCC in AbstractKernelControllerContext has the name EJB3CacheFactoryRegistry, and it is of type org.jboss.ejb3.cache.CacheFactoryRegistry.
Looking at ConfigureAction.setAttributes() it iterates over the properties, and is currently on

AbstractPropertyMetaData@f4561{name=factories value=AbstractMapMetaData@4b5a7b{value=null type=java.util.HashMap}}

This then calls dispatchSetProperty() which ends up in AOPConstructorJoinPoint(0 to create the HashMap value to be configured. So it is not a "wrong" ConstructorInfo, the CacheFactoryRegistry was already created properly. It happens when creating the properties.

Convinced?

[kabirkhan]

Oh yeah, and in the previous failure the error message is

Method with signature get[java.lang.Object] does not exist on class class org.jboss.ejb3.cache.CacheFactoryRegistry

get[java.lang.Object[]] is a method from HashMap, which is the type of the property being created.

[adrian.brock]

Ok, but that has nothing to do with ConfigureAction
(that's just where we found the problem).

The same problem could occur anywhere where it creates collections.
e.g. passing it as a parameter to create()

The problem is that when it is creating say an EJB3CacheRegistry
and as part of one of the callbacks (in this case setting a Map property)
it has to construct invoke AbstractTypeMetaData.createInstance().

NOTE: I don't see any other places where a ConstructorJoinPoint is invoked.

So this goes through the AOPConstructorJoinpoint which expects
there to be a MetaDataStack entry for the Map.

But this Map is not under the direct control of the MC, it has no context
or MDR MetaData.

So the fix is probably two parts.
Can you try this, to see whether it works? There might be
some issues I'm not aware of with passing null on the MetaDataStack to
AOPConstructorJoinPoint?

1) AbstractTypeMetaData needs to mask the EJB3CacheRegistry's
MetaData context when it uses the constructor joinpoint to create the Map.

MetaDataStack.mask();
try
{
 Object result = constructor.dispatch();
}
finally
{
 MetaDataStack.unmask();
}

2) AOPConstructorJoinpoint needs to have code that says if the
MetaDataStack is empty then just invoke parent.dispatch()
rather than doing the proxy factory stuff.

 public Object dispatch() throws Throwable
 {
 Class<?> clazz = constructorInfo.getDeclaringClass().getType();
 MetaData metaData = MetaDataStack.peek();
 if (metaData == null)
 return super.dispatch();

[kabirkhan]

I am still running the aop-mc-int tests, which seem fine so far. On AS startup, your fix gets rid of the previously described problem, but I am seeing one occurrance of another problem.

Stack trace:

AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150
AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276
MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160
AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 177
AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 155
AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 135
AOPConstructorJoinpoint.dispatch() line: 98
AbstractBeanInfo.newInstance(String[], Object[]) line: 269
AbstractBeanInfo.newInstance() line: 263
JBossXBNoSchemaBuilder.createAdapterFactory(Class<BeanAdapterBuilder>, BeanInfo, MethodInfo) line: 1786
JBossXBNoSchemaBuilder.generateType(ClassInfo, boolean) line: 775
JBossXBNoSchemaBuilder.generateBean(ClassInfo, boolean) line: 702
JBossXBNoSchemaBuilder.generateBean(ClassInfo) line: 690
JBossXBNoSchemaBuilder.generateTypeBinding(TypeInfo) line: 469
JBossXBNoSchemaBuilder.resolveTypeBinding(TypeInfo) line: 428
JBossXBNoSchemaBuilder.createElementBinding(TypeInfo, String, boolean) line: 307
JBossXBNoSchemaBuilder.createRootElementBinding(TypeInfo) line: 287
JBossXBNoSchemaBuilder.createRootElements() line: 267
JBossXBNoSchemaBuilder.build() line: 191
JBossXBBuilder.build(Class<?>) line: 118
TomcatDeployer.start() line: 393
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
ReflectionUtils.invoke(Method, Object, Object[]) line: 56
ReflectMethodInfoImpl.invoke(Object, Object[]) line: 110
BasicMethodJoinPoint.dispatch() line: 66
KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 241
KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109
KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 70
StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 221
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: 348
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1461
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 853
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 981
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 903
AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 693
AbstractKernelController(AbstractController).install(ControllerContext) line: 470
BeanMetaDataDeployer.deploy(DeploymentUnit, BeanMetaData) line: 88
BeanMetaDataDeployer.deploy(DeploymentUnit, Object) line: 46
BeanMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62
BeanMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50
DeployerWrapper.deploy(DeploymentUnit) line: 174
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 970
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 991
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 911
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1461
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 853
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 981
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 903
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 741
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 483
DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 594
MainDeployerImpl.process() line: 541
ProfileServiceBootstrap.loadProfile(String) line: 250
ProfileServiceBootstrap.start(Server) line: 135
ServerImpl(AbstractServerImpl).start() line: 409
Main.boot(String[]) line: 209
Main$1.run() line: 544
Thread.run() line: 613 [local variables unavailable]

The class/constructor being used in AOPConstructorJoinPoint is:
public org.jboss.xb.spi.DefaultBeanAdapterBuilder()

The underlying class being installed is org.jboss.web.tomcat.service.deployers.TomcatDeployer, and it barfs in AnnotatedElementMetaDataLoader when it cannot find the following method from DefaultBeanAdapterBuilder. If you want be to look into this in more detail, please let me know

[kabirkhan]

I have commited the changes so far to https://jira.jboss.org/jira/browse/JBMICROCONT-317

[adrian.brock]

So the TomcatDeployer is a similar problem,
but this time it is JBossXB's usage of BeanInfo.newInstance()
which also dispatches a construct joinpoint.

That's one is harder to fix since jboss-reflect can't depend on jboss-mdr
(the dependency is the reverse) to mask the metadata stack.

Maybe we need to think about doing this in a different way so it is less
hacky to differentiate constructions that need to pass a MetaData object
(and should explicitly do so) versus the ad hoc usage of BeanInfo/ConstructorJoinPoints
which don't and shouldn't therefore be creating AOP proxies.

I've started a thread on this in the MC forum
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166401#4166401

[adrian.brock]

I've started a thread on this in the MC forum
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166401#4166401

Hold off on making changes or JIRA issues until we know what we are going to do,
otherwise it is likely you'll have to unpick it all anyway. :-)