Eclipse Community Forums: Virgo » AspectJ LTW with Virgo

Help

Home

Home » Eclipse Projects » Virgo » AspectJ LTW with Virgo

Show: Today's Messages :: Show Polls :: Message Navigator

AspectJ LTW with Virgo [message #646155]

Wed, 22 December 2010 12:06

Frieder Heugel

Messages: 61
Registered: October 2010
Location: Basel, CH

Member

AspectJ LTW with Virgo

Hi guys,

I am trying to get AspectJ LTW working with Virgo (no Spring AOP involved) but for some reason it does not work.

Here is what I have done so far (basically applying the steps mentioned in the quick start guide of the Equinox Aspects project) :

1.) Added org.eclipse.equinox.weaving.hook_1.0.0.v20100503.jar to the lib/ folder
2.) Added com.springsource.org.aspectj.runtime-1.6.8.RELEASE.jar, com.springsource.org.aspectj.weaver-1.6.8.RELEASE.jar and org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar to the lib/kernel/ folder
3.) Added these bundles to the launch configuration
[..]
file:lib/org.eclipse.equinox.weaving.hook_1.0.0.v20100503.ja r,\
file:lib/kernel/com.springsource.org.aspectj.weaver-1.6.8.RELEASE.jar@start,\
file:lib/kernel/com.springsource.org.aspectj.runtime-1.6.8.RELEASE.jar@start,\
file:lib/kernel/org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar@start,\ <-- changed the AspectJ versions from 1.6.3 to 1.6.8.RELEASE
4.) Added the following line to the Equinox configuration in the launch config file
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
5.) Put the AspectJ runtime and weaver bundle into the repository/ext/ folder
6.) Created an aspect and exported the package
for testing purposes I used the following aspect
pointcut all() : call(* *.*(..)) && !within(MyAspect);

before() : all() {
System.out.println("Hello World from MyAspect");
}
7.) Created the aop.xml in META-INF/
8.) Added the necessary entries in MANIFEST.MF (Eclipse-SupplementBundle)
9.) Used maven to build the advice bundle (to avoid version incompabilities between the Eclipse (1.6.11) and the Virgo (1.6. Cool

AspectJ libraries)

While the aspect bundle is working fine with plain Equinox 3.6.1 (and AspectJ 1.6. Cool

with Virgo it does not work. When I deploy the aspect bundle it redeploys all bundles affected by the aspect so it looks like the aspect is recognized but the System.out.println(..) I put in the corresponding advice does not show up (neither on the console nor in the log file). Now I am wondering what might be the problem (there are no exceptions occuring). Is Virgo somehow preventing the aspect from being executed? Does anyone of you have any clue what I am doing wrong here?

Any help on this issue is really appreciated.

Report message to a moderator

Re: AspectJ LTW with Virgo [message #646168 is a reply to message #646155]

Wed, 22 December 2010 14:00

Dmitry Sklyut

Messages: 279
Registered: January 2010

Senior Member

Hello Frieder,

IANAE, but some thoughts here:

1. adding anything to the /lib folder will add that jar to the -cp of the java processes starting the framework/virgo
2. did you remove prior version of aspectj (com.springsource.org.aspectj.weaver-1.6.6.RELEASE.jar) from /repository/ext?

Virgo is split into two regions with support from embedded frameworks. You are deploying aspectj libraries and supporting libraries in kernel region. Depending on how you deploy your aspect bundle (assuming drop into pickup/or web interface) , it might not see required bundles or might get bound to a different instances of bundles. So there might be some classloading issues internally that are stoping aspect from working. These classloading issues might not be visible in logs, that is if there are checks like this:

if (object instaceof SomeClass)  {
// do work
}
// otherwise don't do anything

Because object.class was loaded from userregion and SomeClass was loaded by kernel region - different classloader, instanceof will be false. Even if class.getName is the same for both.

Take a look in /config/org.eclipse.virgo.kernel.userregion.properties specifically at packageImports property. That property specifies packages that are exported from kernel into user region. org.aspectj.* is part of that list, but you might need others.

Also if you don't mind - can you create a bugzilla issue and attach your aspect bundle to it, including detailed steps to recreate. You gave a greave overview in this post, but if you could provide a more detailed instructions (if any) it would help also. For example, what do you mean by this comment:

Quote:

file:lib/kernel/org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar@start,\ <-- changed the AspectJ versions from 1.6.3 to 1.6.8.RELEASE

Regards,
Dmitry

Report message to a moderator

Re: AspectJ LTW with Virgo [message #646177 is a reply to message #646155]

Wed, 22 December 2010 15:04

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

One thing that looks a little wrong is the way you handle the AspectJ bundles. There is a lot of overlap between the weaver and runtime bundles and I doubt that you need then both.

Also the packages org.aspectj.* are imported from the kernel region into the user region, so I doubt that you need to put the AspectJ bundle(s) in repository/ext.

Report message to a moderator

Re: AspectJ LTW with Virgo [message #647446 is a reply to message #646177]

Thu, 06 January 2011 12:55

Frieder Heugel

Messages: 61
Registered: October 2010
Location: Basel, CH

Member

Hi guys,

thx for your input on this topic. Unfortunately I was not able to get this working so far.

@Dmitry

Quote:

2. did you remove prior version of aspectj (com.springsource.org.aspectj.weaver-1.6.6.RELEASE.jar) from /repository/ext?

Not until you asked me about that. Now I did but no change, still no output from the Aspect.

Quote:

Also if you don't mind - can you create a bugzilla issue and attach your aspect bundle to it, including detailed steps to recreate. You gave a greave overview in this post, but if you could provide a more detailed instructions (if any) it would help also. For example, what do you mean by this comment:

I meant that in the bundle there was an optional import statement with version 1.6.3 and I changed that to 1.6.8 (in fact I changed that to [1.6,1.7)). Not sure if that is necessary at all but wanted to be sure. I filed a bug, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=333646. To avoid difficulties I did not change any of the bundles except the provided sample bundles.

@Glyn

Quote:

One thing that looks a little wrong is the way you handle the AspectJ bundles. There is a lot of overlap between the weaver and runtime bundles and I doubt that you need then both.

You are right. I am used to using the AspectJ bundles that are shipped with the Eclipse AJDT installation (building my own OSGi-ready bundles to have the latest AspectJ/AJDT version available and to avoid version incompabilities) and there the Eclipse (AJDT?) team has two different bundles (runtime/weaver) with different packages (no overlap at all). I was not aware that the AspectJ libraries (and therefore the SpringSource EBR bundles too) follow a different approach than the bundles from the AJDT plugin (wondering what might be the reason for that). Thx for the hint.

Quote:

Also the packages org.aspectj.* are imported from the kernel region into the user region, so I doubt that you need to put the AspectJ bundle(s) in repository/ext.

Again thx for the info. The reason why I did that is because the weaver bundle from the kernel folder (com.springsource.org.aspectj.weaver-1.6.6.RELEASE.jar) is also available in repository/ext by default and therefore I thought that it is necessary to put the bundles there (Is there a reason why it is in the ext folder when all packages are exported to the user region anyways?). Another reason is that the Equinox Aspects quick start guide mentions the following: Use Require-Bundle to declare a dependency on org.aspectj.runtime and re-export this dependency. which requires the bundle to be in some repository folder (not sure if package import would be sufficient in this case, tried it but does not work either). Btw it looks like Spring IDE does not recognize any packages that are exported automatically from the lib/ folder as it keeps showing error markers stating that some package imports cannot be resolved. Hope that gets fixed once the tooling has been donated to Eclipse.

Any help for this issue is highly appreciated. Thank you guys.

Frieder

Report message to a moderator

Re: AspectJ LTW with Virgo [message #647455 is a reply to message #647446]

Thu, 06 January 2011 13:54

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Frieder Heugel wrote on Thu, 06 January 2011 12:55

...

@Glyn

Quote:

One thing that looks a little wrong is the way you handle the AspectJ bundles. There is a lot of overlap between the weaver and runtime bundles and I doubt that you need then both.

I'll ask our local expert.

Quote:

Also the packages org.aspectj.* are imported from the kernel region into the user region, so I doubt that you need to put the AspectJ bundle(s) in repository/ext.

The reason is mainly historical, pre-dating the introduction of the user region. In a later release, repository/ext and lib are likely to be merged.

Quote:

Another reason is that the Equinox Aspects quick start guide mentions the following: Use Require-Bundle to declare a dependency on org.aspectj.runtime and re-export this dependency. which requires the bundle to be in some repository folder (not sure if package import would be sufficient in this case, tried it but does not work either).

The current user region design does not allow kernel bundles to be imported into the user region and so require-bundle won't work. I am currently looking at removing this restriction for the next release. Meanwhile, I'm afraid you'll have to make do with multiple package imports.

Quote:

Btw it looks like Spring IDE does not recognize any packages that are exported automatically from the lib/ folder as it keeps showing error markers stating that some package imports cannot be resolved. Hope that gets fixed once the tooling has been donated to Eclipse.

Me too, but you may like to raise a bug on this to increase the chances. Wink

Report message to a moderator

Re: AspectJ LTW with Virgo [message #647876 is a reply to message #647455]

Mon, 10 January 2011 09:40

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Glyn Normington wrote on Thu, 06 January 2011 13:54

Quote:

...
@Glyn

Quote:

One thing that looks a little wrong is the way you handle the AspectJ bundles. There is a lot of overlap between the weaver and runtime bundles and I doubt that you need then both.

I'll ask our local expert.

The reasons are mostly historic. AspectJ has always shipped three jars each is a superset of the previous and includes all of its contents:

aspectjrt.jar - just the runtime
aspectjweaver.jar - the runtime and the weaver
aspectjtools.jar - the runtime and the weaver and the tools

The manifests in those jars are not suitable for use in OSGi since the jars pre-date OSGi becoming popular. That packaging enables the user to simply pick the one jar they need for the task at hand (compiling, loadtime weaving or just running woven code).

When the jars are put into an OSGi environment, they need fixing up. When put into AJDT they are repackaged into org.aspectj.runtime/org.aspectj.weaver/org.aspectj.ajde - corresponding to runtime/weaver/compiler. There is no overlap when they are packaged like this.

Unfortunately, the original, overlapping jars from AspectJ were used as the starting point in the Enterprise Bundle Repository and the manifests are fixed up.

Ultimately, we need to obtain non-overlapping OSGi bundles at which point we would use the weaver and runtime bundles in Virgo.

Would you care to raise an enhancement bug to cover this as it may be a reasonable candidate for Virgo 3.0?

Report message to a moderator

Re: AspectJ LTW with Virgo [message #647906 is a reply to message #647876]

Mon, 10 January 2011 12:09

Frieder Heugel

Messages: 61
Registered: October 2010
Location: Basel, CH

Member

Hi Glyn,

Thank you for the information.

Glyn Normington wrote on Mon, 10 January 2011 04:40

Would you care to raise an enhancement bug to cover this as it may be a reasonable candidate for Virgo 3.0?

Done, see Bug 333855.

Glyn Normington wrote on Thu, 06 January 2011 08:54

Quote:

Me too, but you may like to raise a bug on this to increase the chances. Wink

Could you please tell me where to raise that bug? Do I have to use https://jira.springframework.org/browse/IDE or is there already some place on the Eclipse website for that?

Glyn Normington wrote on Thu, 06 January 2011 08:54

Could you please give me an estimate when you are planing to do that? Will it be available in the next milestone release? I am asking because at the moment I am stuck with this issue and the missing Require-Bundle header is the only reason I can think of right now that might be preventing the aspect from being executed properly. I think having AspectJ LTW support in a runtime environment like Virgo would be a really nice feature and is a perfect match with the modular characteristics of OSGi.

[Updated on: Mon, 10 January 2011 12:11]

Report message to a moderator

Re: AspectJ LTW with Virgo [message #647931 is a reply to message #647906]

Mon, 10 January 2011 14:00

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Frieder Heugel wrote on Mon, 10 January 2011 12:09

Hi Glyn,

Thank you for the information.

You're welcome.

Quote:

Glyn Normington wrote on Mon, 10 January 2011 04:40

Would you care to raise an enhancement bug to cover this as it may be a reasonable candidate for Virgo 3.0?

Done, see Bug 333855.

Thanks.

Quote:

Glyn Normington wrote on Thu, 06 January 2011 08:54

Quote:

Me too, but you may like to raise a bug on this to increase the chances. Wink

Could you please tell me where to raise that bug? Do I have to use https://jira.springframework.org/browse/IDE or is there already some place on the Eclipse website for that?

Since the Virgo tooling is being donated to Eclipse under the Virgo project, please raise the bug against Virgo.

Quote:

Glyn Normington wrote on Thu, 06 January 2011 08:54

It might make the next milestone, but there's quite a lot of work remaining to get the prototype on the branch into good shape and add this feature. Meanwhile, I am going to take an initial look at bug 333646 in this week's sprint.

Report message to a moderator