anonymous wrote : I tried altering the following part of the replace call in
AspectManager.getInstrumentedClassLoader():
Yes, I would have added another test based on the number of parameters but it
would have resulted in the same. I downloaded the 1.4.2 JDK over the weekend
and that appears
There are two parts to this, getting the classloader to intercept the calls to
defineClass0 and getting AOP to work with any classloader setup.
The first one is easy, just a simple modification to the code that instruments
the classloader should do it.
The second one involves a change to the
anonymous wrote : It looks like it is completely replacing the private native
defineClass0 method on the classloader
It's not replacing the call, just allowing the AspectManager to transform the
loaded bytes before calling defineClass0.
anonymous wrote : IBM's JVM has a similar defineClass0
Your config is wrong, you should be using AspectDeployer32 instead of
AspectDeployer.
Kev
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3855873#3855873
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3855873
anonymous wrote : I suggest using the precompiler because currently, load-time
transformation is a HUGE memory hog.
I'm nearly finished an alternative load-time which has a much better memory footprint.
I've been working on a different version of the classpool that doesn't store the same
anonymous wrote : It is not correct type of comparition.
The comparison relates to the additional functionality that PrintWriter.println
provides in and above that provided by Writer.write.
In this case it is simple, just adding the correct eol characters for the platform,
but it is an example
Hiya guys.
I'm busy tracking down JacORB problems at the moment so missed this.
The code that I have given you is 'fully functional' in so far as it provides the
advices that remove the code duplication. Give it a try, you may like it :-)
I tend to agree with Bill on the matter of simplicity.
anonymous wrote : What type of simplicity are you talking about?
I was talking about the simplicity at runtime, i.e. calling the aspects, and not
during bytecode annotation.
anonymous wrote : The case we're discussing (types of advices) is simple to imagine.
Come on..
It is very simple to
Hiya Tomasz.
I eventually found some time to put together one of my ideas, here's an example using
it (uses the annotation compiler).
The annotation interfaces.
package knrc.beforeAfter2;
|
| /**
| * @author kevin
| */
| public interface after
| {
| }
package
Hiya Tomasz.
anonymous wrote : Yes it works. I'm impressed.
Thanks, I aim to please ;-)
anonymous wrote : Ok. But still it is a workaround, although smart and works for this
example.
I wouldn't call it a workaround, just a clean design that refactors common code and is
based on the JBoss API
Hiya Bill.
The issue is that the findMethodByHash method assumes that the clazz argument is a
class, in this case it is an interface. The bug is that the method being searched is
in a super interface of the one being called, hence it is never found.
I have a simple test case that reproduces
I'll link it in to the basic.AOPTester and send the patch to you.
Kev
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3849303#3849303
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3849303
Sorry Bill, just noticed your posting.
The problem happens when you use $instanceof{}. If you do not use it then the call
does not get intercepted.
Kev
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3849311#3849311
Reply to the post :
13 matches
Mail list logo
