I'll give it a shot. (Both turn on debug in debug and verbose in staging.)
Mike
--------------------------
Michael Laccetti
416-558-9718
-----Original Message-----
From: aspectj-users-boun...@eclipse.org <aspectj-users-boun...@eclipse.org>
To: aspectj-users@eclipse.org <aspectj-users@eclipse.org>
Sent: Mon Feb 09 17:46:26 2009
Subject: Re: [aspectj-users] WebLogic 9.2 + AspectJ = boom?
I am half wondering if the ClassNotFoundExceptions are entirely red herrings.
They are not nice (and indicate I think we have a bug) but it is rare that
anyone turns on AspectJ trace - I suspect if you turned on trace on your
working cluster, you might well see them! So, going back to the original note,
I would like to know how the AOP stuff is actually not working? In your
aop.xml you can turn on -verbose, and additionally -showWeaveInfo as another
option which will tell us if the weaver is advising where you want to advise.
cheers,
Andy.
2009/2/9 Michael Laccetti <mich...@laccetti.com>
I love straw grasping. :)
I've attached the stack, from just a bit before the exceptions, to just
after. Let me know if there is anything else I can dig up. (I forgot to turn
on verbose in the config file; next release will have that.)
Mike
From: aspectj-users-boun...@eclipse.org
[mailto:aspectj-users-boun...@eclipse.org] On Behalf Of Andy Clement
Sent: February-09-09 4:14 PM
To: aspectj-users@eclipse.org
Subject: Re: [aspectj-users] WebLogic 9.2 + AspectJ = boom?
Hi Michael,
I see you are also having a problem for another type there, and it also
trying multiple prefixes: java.lang, and com.cryptologic.bsg.aspect:
com.cryptologic.bsg.aspect.com.cryptologic.bsg.service.impl.EcashPlayerAccountServiceImpl
As the -Xset option did not fix it - that suggests the classloader is
OK (but I guess we might have known that as it deploys fine on your other
system).
Do you have the full stack traces for the ClassNotFound problems? Very
peculiar that the java.lang. prefixed CNFE comes out before the CNFE for the
non-prefixed version.
I'm kind of grasping at straws here - since it works on one system but
not on the other, I'm finding it difficult to work out what AJ might be doing
wrong, or what assumption it is making that isn't valid across all
configurations.
Is there by any chance another older copy of the code in some other jar
in the system configuration or on the classpath ? If an old version of the
application/aspect got loaded by a different loader (maybe a loader higher in
the loader hierarchy), then anything below that loader in the classloader
hierarchy would not be visible to the weaver. Is the classpath different in
any way across these configurations?
Andy.
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
