January 2010 - jboss-dev-forums - Jboss List Archives

[JBoss AOP Development] New message: "Re: Help: Error [Instrumentor] AOP Instrumentor failed"

by Kabir Khan

JBoss 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

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by Brian Stansberry

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/521757#521757 Author : Brian Stansberry Profile : http://community.jboss.org/people/bstansberry@jboss.com Message: -------------------------------------------------------------- > mailto:bstansberry@jboss.com wrote: > So, say some time between Feb 11 and 15, depending on how M2 goes. Just to clarify: work on this on AS trunk would *start* some time between Feb 11 and Feb 15, not necessarily be completed in that window. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521757#521757

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by Brian Stansberry

JBoss 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

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521750#521750 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I have added some simple scoping handling, which brings KernelAllTestSuite down to 11 errors and 24 failures. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521750#521750

14 years, 5 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: Help: Error [Instrumentor] AOP Instrumentor failed"

by Flavia Rainone

JBoss 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

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Ales Justin

JBoss 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

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521733#521733 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I don't think dependsOnMe will work. 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. Have I got the wrong idea/am I missing something? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521733#521733

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521731#521731 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > alesj wrote: > > I had something simpler in mind, not "indexing" per DependencyItem type. > > Something in the lines of: > (a) install/move context > (b) find it's dependencies Here, I think you mean the dependsOnMe dependencies, I'll look into that > alesj wrote: > > This way we wouldn't always check all contexts, > just the ones that actually can be moved. Just to be clear, we don't check all the contexts the way I have set it up either -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521731#521731

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Ales Justin

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521725#521725 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- I had something simpler in mind, not "indexing" per DependencyItem type. Something in the lines of: (a) install/move context (b) find it's dependencies (c) for each dependency do (a) This way we wouldn't always check all contexts, just the ones that actually can be moved. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521725#521725

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Aggregated Microcontainer JavaDoc"

by Thomas Diesler

JBoss development, A new message was posted in the thread "Aggregated Microcontainer JavaDoc": http://community.jboss.org/message/521714#521714 Author : Thomas Diesler Profile : http://community.jboss.org/people/thomas.diesler@jboss.com Message: -------------------------------------------------------------- I made an effort to get started on https://jira.jboss.org/jira/browse/JBMICROCONT-442 Please have a look at http://community.jboss.org/thread/147164 in JBossAS Development -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521714#521714

14 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2010