[aspectj-users] Websphere, outdated aspectjrt.jar

Try this:

ajc -Xajruntimetarget:1.2 Blah.java

or

<iajc ...... X="ajruntimetarget:1.2" .... >

Andy.

Post by Pavel
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Pavel

2008-03-19 17:14:27 UTC

Thanks for the tip Andy.

Unfortunately with or without the X="ajruntimetarget:1.2" I end up with the
same error,

java.lang.NoSuchMethodError:
org/aspectj/runtime/reflect/Factory.makeMethodSig(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;

Pavel

Post by Andy Clement
ajc -Xajruntimetarget:1.2 Blah.java
or
<iajc ...... X="ajruntimetarget:1.2" .... >
Andy.

Post by Pavel
Greetings,
I noticed that woven classes do not deploy on WAS 6.1 due to old version

Post by Pavel
aspectjrt.jar in server lib folder. It all works fine on JBoss.
Changing anything outside of my application EAR is not an option,

especially

Post by Pavel
when it comes to server libraries.
Currently there is only one aspect for tracking domain object

"dirtiness".

Post by Pavel
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.

Post by Pavel
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,

Post by Pavel
but this will make things harder, and possibly slower.
Thanks,
Pavel
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Bhaskar Maddala

2008-03-19 17:24:05 UTC

I think as Scott previously mentioned you should try "Parent-last" for
the classloader policies in websphere

In the past I have used the classloader policies to address similar
issues, although not specifically related to aspectj (mine was with
xerces, I believe, but memory fails me)

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzatz/51/program/clsadmcns.htm

Thanks
Bhaskar

Post by Pavel
Thanks for the tip Andy.
Unfortunately with or without the X="ajruntimetarget:1.2" I end up with the
same error,
org/aspectj/runtime/reflect/Factory.makeMethodSig(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;
Pavel

Post by Andy Clement
ajc -Xajruntimetarget:1.2 Blah.java
or
<iajc ...... X="ajruntimetarget:1.2" .... >
Andy.

Post by Pavel
Greetings,
I noticed that woven classes do not deploy on WAS 6.1 due to old version

Post by Pavel
aspectjrt.jar in server lib folder. It all works fine on JBoss.
Changing anything outside of my application EAR is not an option,

especially

Post by Pavel
when it comes to server libraries.
Currently there is only one aspect for tracking domain object

"dirtiness".

it.

proxies,

_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Andy Clement

2008-03-19 17:56:09 UTC

well... i am confused because it works for me and this is what it was
designed for.... Here is my build.xml fragment:

<iajc X="ajruntimetarget:1.2"
sourceroots="src" source="1.5" classpath="d:/aspectj1.6-dev/lib/aspectjrt.jar"/>

and the resultant class files do not refer to the multi-string factory
method makeMethodSig, they just call the original single String
makeMethodSig that existed in Aspectj1.2:

21: invokevirtual #103; //Method
org/aspectj/runtime/reflect/Factory.makeMethodSig:(Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;

are you sure you aren't picking up some other woven code that you are
not able to recompile that still refers to the new form that isnt in
the old WAS aspectjrt.jar? If so, you may have to try the classloader
policy the other guys are suggesting.

Andy.

Post by Andy Clement
ajc -Xajruntimetarget:1.2 Blah.java
or
<iajc ...... X="ajruntimetarget:1.2" .... >
Andy.

Post by Pavel
Greetings,
I noticed that woven classes do not deploy on WAS 6.1 due to old version

Post by Pavel
aspectjrt.jar in server lib folder. It all works fine on JBoss.
Changing anything outside of my application EAR is not an option,

especially

Post by Pavel
when it comes to server libraries.
Currently there is only one aspect for tracking domain object

"dirtiness".

it.

proxies,

_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Pavel

2008-03-19 22:29:16 UTC

Andy,

After reading your response I reviewed build scripts carefully and found one
<iajc> instance where I missed the X="ajruntimetarget:1.2".
After adding that attribute the application did compile, deploy, and even
pass some watir tests on WAS.

I don't yet understand all the implications of having runtime target of 1.2,
but so far the results look encouraging to me. I'll try to followup on the
final results, but if I don't, you can safely assume everything worked fine
on both JBoss and WAS.

Many thanks,
Pavel

Post by Andy Clement
well... i am confused because it works for me and this is what it was
<iajc X="ajruntimetarget:1.2"
sourceroots="src" source="1.5"
classpath="d:/aspectj1.6-dev/lib/aspectjrt.jar"/>
and the resultant class files do not refer to the multi-string factory
method makeMethodSig, they just call the original single String
21: invokevirtual #103; //Method
org/aspectj/runtime/reflect/Factory.makeMethodSig:(Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;
are you sure you aren't picking up some other woven code that you are
not able to recompile that still refers to the new form that isnt in
the old WAS aspectjrt.jar? If so, you may have to try the classloader
policy the other guys are suggesting.
Andy.

Post by Pavel
Thanks for the tip Andy.
Unfortunately with or without the X="ajruntimetarget:1.2" I end up with

the

Post by Pavel
same error,

org/aspectj/runtime/reflect/Factory.makeMethodSig(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;

Post by Pavel
Pavel

Post by Andy Clement
ajc -Xajruntimetarget:1.2 Blah.java
or
<iajc ...... X="ajruntimetarget:1.2" .... >
Andy.

Post by Pavel
Greetings,
I noticed that woven classes do not deploy on WAS 6.1 due to old

version

Post by Pavel
of

Post by Pavel
aspectjrt.jar in server lib folder. It all works fine on JBoss.
Changing anything outside of my application EAR is not an option,

especially

Post by Pavel
when it comes to server libraries.
Currently there is only one aspect for tracking domain object

"dirtiness".

Post by Pavel
The pointcut captures execution of set* methods, and around advice

uses

Post by Pavel
JoinPointStaticPart to invoke corresponding getter and compare

result

Post by Pavel
against value being set. The aspect is woven at build time with

<iajc>.

Post by Pavel
As I understand, JoinPointStaticPart is what makes classes

dependent on

Post by Pavel
aspectjrt.jar, but I'm not sure if the aspect can be implemented

without

Post by Pavel
it.

Post by Pavel
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

Post by Pavel
with AspectJ 1.5. I was hoping there is some sort of non-intrusive

known

Post by Pavel
solution/workaround.
My last resort is to drop AspectJ and try to get away with spring

proxies,

_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Scott Bartram

2008-03-19 13:32:43 UTC

Have you tried setting the application classloader to "parent-last" ?

Post by Pavel
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Pavel

2008-03-19 22:51:30 UTC

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

Post by Scott Bartram
Have you tried setting the application classloader to "parent-last" ?
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.xwith 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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Bhaskar Maddala

2008-03-20 15:16:29 UTC

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

Post by Pavel
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

Have you tried setting the application classloader to "parent-last" ?
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
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Pavel

2008-03-21 21:51:55 UTC

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)><david+***@davidkarlsen.com>
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

Post by Pavel
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

Post by Pavel
Scott,
I haven't tried it yet, and perhaps with help of Andy I wouldn't have

to,

Post by Pavel
but my major concern about changes in classloading order is possible
regressions. The application is quite large, with a limited test

coverage,

Post by Pavel
yet lots of QA effort has been put to make sure everything is more or

less

Post by Pavel
stable.
With classloading changed, I see no easy way to see if things still do

work.

Post by Pavel
But anyway, thank you for the advice.
Pavel

Post by Pavel
Have you tried setting the application classloader to "parent-last" ?
Greetings,
I noticed that woven classes do not deploy on WAS 6.1 due to old

version

Post by Pavel
of aspectjrt.jar in server lib folder. It all works fine on JBoss.

Post by Pavel
Changing anything outside of my application EAR is not an option,

especially when it comes to server libraries.

Post by Pavel
Currently there is only one aspect for tracking domain object

"dirtiness".

Post by Pavel
As I understand, JoinPointStaticPart is what makes classes dependent

Post by Pavel
aspectjrt.jar, but I'm not sure if the aspect can be implemented without

it.