Re: [aspectj-users] Websphere, outdated aspectjrt.jar

[Pavel <pagrus@xxxxxxxxx>]

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)>
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 <maddalab@xxxxxxxxx> 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 <pagrus@xxxxxxxxx> 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 <scottb@xxxxxxxxxxxx> 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
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
>
>
>
> _______________________________________________
>  aspectj-users mailing list
>  aspectj-users@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

-- 
Best regards,
Pavel