Comment 1 Andrew Clement 2009-01-15 12:34:57 EST

I cannot tell what has happened from the stack trace unfortunately, but I have just committed some diagnostics at that point - these will be in todays dev build.

It may have been addressed already since you are reportedly on 1.6.2 and the latest AJ is 1.6.3, but I don't remember fixing anything in this particular area of the code.  The dev build will be updated here in a couple of hours:

http://www.eclipse.org/aspectj/downloads.php

Please let me know what the diagnostics say - they will at least indicate the types involved when the failure occurred.  I have my suspicions what it will be, but need those diagnostics to be sure.

Comment 2 Andrew Clement 2009-01-26 22:57:10 EST

managed to collect any diagnostics yet?

Comment 3 Wim Deblauwe 2009-01-27 03:44:34 EST

Not yet, I am sorry. I hope to test next week or something.

Comment 4 Wim Deblauwe 2009-02-03 09:37:44 EST

Created attachment 124544 [details]
ajcore dump with test version

Comment 5 Andrew Clement 2009-02-03 11:50:31 EST

I see from the core, the exception is now:

java.lang.RuntimeException: Can't find type com.traficon.tmsng.server.api.service.impl.filter.FilterServiceImpl
	at org.aspectj.weaver.World.handleRequiredMissingTypeDuringResolution(World.java)

Should that type be found?  Is it on your classpath when running the system?

Comment 6 Wim Deblauwe 2009-02-03 15:35:22 EST

I don't believe it is. I get this exception during using GridGain (see http://www.gridgain.org/). They have a system called peer class loading, where they load classes over the network. 
Come to think of it, I have this exception as soon as I start a node (JVM) that has this class, but on a JVM that does not have this class on the 'normal' classpath.

Is there extra debugging I can enable to see where this class is loaded? Because the JVM that gives the exception normally does not need that class at all.

regards,

Wim

Comment 7 Andrew Clement 2009-02-03 16:39:42 EST

The more complete stack for the exception:

java.lang.RuntimeException: Can't find type com.traficon.tmsng.server.api.service.impl.filter.FilterServiceImpl
	at org.aspectj.weaver.World.handleRequiredMissingTypeDuringResolution(World.java:320)
	at org.aspectj.weaver.World.resolve(World.java:279)
	at org.aspectj.weaver.World.resolve(World.java:191)
	at org.aspectj.weaver.UnresolvedType.resolve(UnresolvedType.java:615)
	at org.aspectj.weaver.bcel.BcelObjectType.getOuterClass(BcelObjectType.java:825)
	at org.aspectj.weaver.AbstractReferenceTypeDelegate.getFormalTypeParametersFromOuterClass(AbstractReferenceTypeDelegate.java:103)
	at org.aspectj.weaver.bcel.BcelObjectType.ensureGenericSignatureUnpacked(BcelObjectType.java:743)
	at org.aspectj.weaver.bcel.BcelObjectType.getSuperclass(BcelObjectType.java:208)
	at org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:721)
	at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:1385)

I'd suspect it is an inner type of com.traficon.tmsng.server.api.service.impl.filter.FilterServiceImpl that is giving problems - although how the inner can be found but not the outer, who knows. 

> Because the JVM that gives the exception normally does not need that class
> at all.

As I would normally say here, AspectJ LTW may need more information than you might need to just run an application normally - weaving can effectively need the same set of types around as were used at compilation time in order to determine everything it needs to know.  A regular run of this application would probably never unpack the generic signature attribute, and yet AspectJ might in order to work out if a pointcut really does match.  We may be able to craft a within clause to exclude the problematic parts of the application configuration.

But there is no trickery in AspectJ, we just use the regular delegating class loader model to get hold of types -  so to load this type we would ask the classloader the weaver is associated with.  If that cannot answer with the type then it could lead to this problem.  I don't know anything about the peer delegation model being used here, but this is what we'd do:

Class c = Class.forName(forReferenceType.getName(), false, usingClassLoader);

where usingClassLoader is the one related to the weaver.  
forReferenceType would be com.traficon.tmsng.server.api.service.impl.filter.FilterServiceImpl

We have talked about making the LTW world have a pluggable loader model to support unusual configurations but nothing has been done to support it yet.

However... I've just rechecked the debug information I included in the latest builds.  For some reason my latest diagnostics aren't actually triggering (which would tell us about the types involved) because your latest dump gives the failing reason as a RuntimeException - and that is occurring earlier than your previous CCE (from the first comment on this bug). hmmm.  Maybe more has changed since 1.6.2 than I thought.

I can put in more diagnostics that will tell you which type is eventually leading to this being woven - but the end result may be that you just need to ensure this type is around and accessible, that would be the simplest option.

Comment 8 Wim Deblauwe 2009-02-11 03:42:21 EST

Hi,

I tested again with the 1.6.4 development version and I got no more exceptions. The other one I talked about was because there was a 1.6.2 in the classpath of one of the JVMs. So I will be moving to 1.6.4 as soon as it gets released (any clue on the timing?)

regards,

Wim

Comment 9 Andrew Clement 2009-02-11 11:18:11 EST

Hi Wim,

AspectJ releases are currently at every 3 months.  The next is due at the end of March, although it might come in early depending on whether I want to get it out ahead of Eclipse Con.

I will also hopefully have an automated way to get it into maven by then too.

Comment 10 Andrew Clement 2009-02-24 20:37:11 EST

Given that this is working in 1.6.4 dev builds I propose we close it now - we can easily reopen if something like this crops up in the future.