Posting this on behalf of David J. M. Karlsen, who relied to me privately. Again, in my case targeting 1.2 runtime in <iajc> did the trick, but other cases also possible. ---------------------------------------------------------
<Please forward this to the aspectJ users list on behalf of me - as I cannot post (I'm subscribing with the <(email was here)><[EMAIL PROTECTED]> address to take advantage of automatic filtering through Postfix)>: I had to fight this for some time too. Problem: AspectJ is in the bootclassloader of WAS (and an very old version as well). App (that is - code loaded with EAR classloader or lower) should use some 1.5 aspects. You don't want to turn the EAR-classloader up-side-down (e.g. parent last) to avoid havoc with all other classes (e.g. xml apis and what-not). Trust me - you really don't want to to this. What I came up with: 1. Create a shared library definition for aspectj 1.5. 2. Create a new classloader on app-server level - turn this classloader (set parent last). 3. add the shared library in defined in 1) to this classloader. voila. now you have a classloader which will pick up the new aspectj version - but let all other "normal" loading pass through to the top of the hierarchy (because you've only defined aspectj libs at this level). Haven't expirienced any trouble thus far. Happy hacking - and pleace PMR IBM. ----- http://www.davidkarlsen.com On Thu, Mar 20, 2008 at 5:16 PM, Bhaskar Maddala <[EMAIL PROTECTED]> wrote: > >> my major concern about changes in classloading order is possible > regressions > > Hmm, interesting that you would say that, since Parent-Last is the > best way I have found to make sure I am running (in container) against > the same jar files that I used for unit testing (out of container), > i.e. to say that I think it is fairly safe, provided you do not rely > entirely on in container testing, in which case you are better off > with your strategy of not changing class loading hierarchy. > > Bhaskar > > On Wed, Mar 19, 2008 at 6:51 PM, Pavel <[EMAIL PROTECTED]> wrote: > > Scott, > > > > I haven't tried it yet, and perhaps with help of Andy I wouldn't have > to, > > but my major concern about changes in classloading order is possible > > regressions. The application is quite large, with a limited test > coverage, > > yet lots of QA effort has been put to make sure everything is more or > less > > stable. > > > > With classloading changed, I see no easy way to see if things still do > work. > > But anyway, thank you for the advice. > > > > Pavel > > > > > > > > On Wed, Mar 19, 2008 at 3:32 PM, Scott Bartram <[EMAIL PROTECTED]> > wrote: > > > > > > > > Have you tried setting the application classloader to "parent-last" ? > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 18, 2008, at 8:14 PM, Pavel wrote: > > > > > > > > > > > > > > > Greetings, > > > > > > I noticed that woven classes do not deploy on WAS 6.1 due to old > version > > of aspectjrt.jar in server lib folder. It all works fine on JBoss. > > > Changing anything outside of my application EAR is not an option, > > especially when it comes to server libraries. > > > > > > Currently there is only one aspect for tracking domain object > "dirtiness". > > The pointcut captures execution of set* methods, and around advice uses > > JoinPointStaticPart to invoke corresponding getter and compare result > > against value being set. The aspect is woven at build time with <iajc>. > > > As I understand, JoinPointStaticPart is what makes classes dependent > on > > aspectjrt.jar, but I'm not sure if the aspect can be implemented without > it. > > > > > > Can you please suggest a way out? To me this issue looks like a bold > > showstopper - you cannot build production-ready applications for WAS 6.x > > with AspectJ 1.5. I was hoping there is some sort of non-intrusive known > > solution/workaround. > > > My last resort is to drop AspectJ and try to get away with spring > proxies, > > but this will make things harder, and possibly slower. > > > > > > Thanks, > > > Pavel _______________________________________________ > > > > > > aspectj-users mailing list > > > [email protected] > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > > > > > _______________________________________________ > > > aspectj-users mailing list > > > [email protected] > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > > > > > > > > > > _______________________________________________ > > aspectj-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > -- Best regards, Pavel
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
