[JBoss AOP Development] New message: "Re: Help: Error [Instrumentor] AOP Instrumentor failed"
by Kabir Khan
User development,
A new message was posted in the thread "Help: Error [Instrumentor] AOP Instrumentor failed":
http://community.jboss.org/message/521769#521769
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> mailto:flavia.rainone@jboss.com wrote:
>
> Taking a look at the piece of code that throws that exception, in GeneratedAdvisorInstrumentor.createAdvisorCtors:
>
> //This will be called when a class instantiates its advisor
> CtConstructor ctor = CtNewConstructor.defaultConstructor(genadvisor);
> ctor.setBody(
> "{" +
> " super(\"" + clazz.getName() + "\"); " + // <<<<<<<<<<<<<<<<<<<
> " initialise(org.jboss.aop.AspectManager.instance(org.jboss.aop.advice.SecurityActions.getClassLoader(this.getClass())), false);" + //Use the CL of the class, since we may be in a scoped loader
> "}");
> genadvisor.addConstructor(ctor);
>
>
>
>
> I think it doesn't make too much sense, since the constructor is created in the previous line.
>
> Maybe this is a Javassist bug. Kabir, what do you think of this?
I remember seeing this error in the past, but not exactly what causes it. I think the problem is with the call to super(String) that I marked. Is the super class getting woven?
Actually looking at http://github.com/apache/ode/blob/a77d1ebd590f879d9d381e779493b08b8d5ff89... it seems to be a base class so that there should be no super advisor. If I am looking at the right version of SoapExternalService, the question is why does it think it is not the base class?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521769#521769
16 years, 3 months
[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"
by Brian Stansberry
User development,
A new message was posted in the thread "Classloader VFS3 Integration":
http://community.jboss.org/message/521754#521754
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
>
> I think we should just set a reasonable date when we're gonna change them all at once.
> We give devs time till then - properly warn/promote this date.
> Then branch previous stuff to right branch versions, and move VFS3 stuff to respected trunks.
>From a logistical point of view, the ideal time to do this is immediately after the tag of AS 6.0.0.M2[1]. So, say some time between Feb 11 and 15, depending on how M2 goes.
However, the integration cutoff for M2 is Jan 31. After that date, work on M2 should be restricted to AS trunk itself. So that leaves a 2 week window where work can be done on external projects.
[1] Actually, probably after the branch, not the tag. I'd prefer to branch then tag, so any QE work for the release can be done against the branch, allowing trunk to be reopened quickly to development.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521754#521754
16 years, 3 months
[JBoss AOP Development] New message: "Re: Help: Error [Instrumentor] AOP Instrumentor failed"
by Flavia Rainone
User development,
A new message was posted in the thread "Help: Error [Instrumentor] AOP Instrumentor failed":
http://community.jboss.org/message/521746#521746
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
Taking a look at the piece of code that throws that exception, in GeneratedAdvisorInstrumentor.createAdvisorCtors:
//This will be called when a class instantiates its advisor
CtConstructor ctor = CtNewConstructor.defaultConstructor(genadvisor);
ctor.setBody(
"{" +
" super(\"" + clazz.getName() + "\"); " +
" initialise(org.jboss.aop.AspectManager.instance(org.jboss.aop.advice.SecurityActions.getClassLoader(this.getClass())), false);" + //Use the CL of the class, since we may be in a scoped loader
"}");
genadvisor.addConstructor(ctor);
I think it doesn't make too much sense, since the constructor is created in the previous line.
Maybe this is a Javassist bug. Kabir, what do you think of this?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521746#521746
16 years, 3 months
[JBoss Microcontainer] New message: "Fluctuating uninstall"
by Carlo de Wolf
User development,
A new message was posted in the thread "Fluctuating uninstall":
http://community.jboss.org/message/521742#521742
Author : Carlo de Wolf
Profile : http://community.jboss.org/people/wolfc
Message:
--------------------------------------------------------------
I'm encountering a pendulous bug in the naming deployers [1]. Whenever I run the tests I get a failure about 50% of the time.
On a glance it looks like a race condition, but there are no multiple threads involved.
I fail to see where some non-deterministic behavior is causing an non-repeatable result.
The failure encountered is:
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.naming:application=testApp,module=moduleA,component=component1
> at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:125)
> at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1448)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1166)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1187)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1219)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1107)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:783)
> at org.jboss.deployers.plugins.main.MainDeployerImpl.deploy(MainDeployerImpl.java:549)
> at org.jboss.reloaded.naming.deployers.test.simple.NameReferencesTestCase.testModuleName(NameReferencesTestCase.java:96)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Caused by: java.lang.IllegalStateException: jboss.naming:application=testApp,module=moduleA,component=component1 is already installed.
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> ... 45 more
>
[1] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trun...
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521742#521742
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Ales Justin
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/521741#521741
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> If we have a context A and context B depends on that. If we install context B first, and then install context A, context A's dependsOnMe does not get populated until we resolve context B's iDependOn items. There is nothing there to tell us which contexts to try to resolve, so we need to look at all contexts to do it this way.
Ah, yes, you're right. DependsOnMe is not set until you resolve it from the "other" side.
So, I guess what you're doing is OK, as there is no other way as to go per dependency type,
and try to figure out what is "dependsOnMe" from the dependency item.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521741#521741
16 years, 3 months