Community
Participate
Working Groups
Build Identifier: When applying the steps mentioned in the Equinox Aspects quick start guide (http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php) to Virgo the aspect bundles do not work properly while at the same time are working fine with standalone Equinox. Used runtimes/bundles: Virgo Web Server 2.1.0.RELEASE Equinox 3.6.1.R36x_v20100806 Gemini Blueprint 1.0.0.M1 Spring Framework 3.0.0.RELEASE com.springsource.org.aspectj.weaver-1.6.6.RELEASE.jar org.eclipse.equinox.weaving.hook_1.0.0.v20100503.jar (can be found in the Equinox SDK) org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar (can be found in the Equinox SDK) Attached example bundles As one can see as soon as the aspect bundle has been deployed the lifecycle of the referenced bundle (bp bundle) is affected but nothing happens in regards to the aspect itself. Reproducible: Always Steps to Reproduce: 1. Add org.eclipse.equinox.weaving.hook_1.0.0.v20100503.jar to the lib/ folder 2. Add org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar to the lib/kernel/ folder 3. Edit lib/org.eclipse.virgo.kernel.launch.properties and add two entries - file:lib/org.eclipse.equinox.weaving.hook_1.0.0.v20100503.jar,\ - file:lib/kernel/org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar@start,\ 4. Add osgi.framework.extensions=org.eclipse.equinox.weaving.hook to the Equinox configuration section in lib/org.eclipse.virgo.kernel.launch.properties 5. OPTIONAL: Edit config/serviceability.xml and add the following loggers <logger level="DEBUG" name="System.out"> <appender-ref ref="STD_OUT"/> </logger> <logger level="DEBUG" name="System.err"> <appender-ref ref="STD_OUT"/> </logger> 6. Start Virgo and drop org.example.blueprint-1.0.0.jar in pickup/ 7. Drop org.example.aspect-1.0.0a.jar in pickup/ 8. Check console output/log file
Created attachment 186160 [details] Example bundle
Created attachment 186161 [details] Example aspect bundle (with Require-Bundle header)
Created attachment 186162 [details] Example aspect bundle (with Package-Import header)
(In reply to comment #2) > Created attachment 186161 [details] > Example aspect bundle (with Require-Bundle header) Looks like I uploaded the wrong bundle. It is basically the same as the 3rd bundle but using Require-Bundle instead of Import-Package. I will upload the right bundle as soon as I am back at work tommorrow.
Created attachment 186247 [details] Example aspect bundle (with Require-Bundle header)
Please note that Virgo currently embeds and is based on Spring DM 1.2.1 rather than Gemini Blueprint. Bug 317943 covers the upgrade to Gemini Blueprint. We have not tested Gemini Blueprint in Virgo and so it is not currently supported as it is likely to conflict with the Spring DM extender. So I would like to clarify whether this bug really requires Gemini Blueprint 1.0.0.M1. This is mentioned under "Used runtimes/bundles" but no mention is made of it under "Steps to Reproduce".
Ignoring blueprint for the moment and continuing to set up, when I included the loggers in step 5, I also had to include a suitable appender, e.g. <appender name="STD_OUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </encoder> </appender>
(In reply to comment #6) > Please note that Virgo currently embeds and is based on Spring DM 1.2.1 rather > than Gemini Blueprint. Bug 317943 covers the upgrade to Gemini Blueprint. We > have not tested Gemini Blueprint in Virgo and so it is not currently supported > as it is likely to conflict with the Spring DM extender. > > So I would like to clarify whether this bug really requires Gemini Blueprint > 1.0.0.M1. This is mentioned under "Used runtimes/bundles" but no mention is > made of it under "Steps to Reproduce". Deploying org.example.blueprint-1.0.0.jar in step 6 results in: org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'org.example.blueprint' at version '1.0.0': Import-Bundle with symbolic name 'org.eclipse.gemini.blueprint.core' in version range '[1.0.0.M1, 1.0.0.M1]' could not be satisfied so it seems that the example really does require blueprint, which is worrying.
Since org.example.blueprint-1.0.0.jar appears to use only Blueprint spec features, it *may* be possible to get away with running Blueprint in Virgo in parallel with Spring DM - the two should only interfere on (Virgo) bundles that use Spring DM. Anyway, it's worth a try and should be instructive. I added the Gemini Blueprint 1.0.0.M1 core, extender, and io bundle to repository/usr along with gemini.blueprint.plan containing the following: <plan name="gemini.blueprint" version="1.0" scoped="false" atomic="false" xmlns="http://www.eclipse.org/virgo/schema/plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.eclipse.org/virgo/schema/plan http://www.eclipse.org/virgo/schema/plan/eclipse-virgo-plan.xsd"> <artifact type="bundle" name="org.eclipse.gemini.blueprint.core" version="[1, 1.1)"/> <artifact type="bundle" name="org.eclipse.gemini.blueprint.extender" version="[1, 1.1)"/> <artifact type="bundle" name="org.eclipse.gemini.blueprint.io" version="[1, 1.1)"/> </plan> (Note that I'm reproducing this bug on master and so the plan schema is at eclipse.org. To use this approach on 2.1.0, you'll have to change the xmlns and xsi:schemaLocation - see repository/ext/org.eclipse.virgo.kernel.userregion.springdm.plan for an example.) Then I changed config/org.eclipse.virgo.kernel.userregion.properties and modified the initialArtifacts property thus (with no line breaks): initialArtifacts=repository:plan/org.eclipse.virgo.kernel.userregion.springdm, repository:plan/org.eclipse.virgo.web, repository:plan/gemini.blueprint After restarting Virgo, org.example.blueprint-1.0.0.jar deployed successfully and I can observe its services using the admin console. On to step 7...
(In reply to comment #6) > Please note that Virgo currently embeds and is based on Spring DM 1.2.1 rather > than Gemini Blueprint. Bug 317943 covers the upgrade to Gemini Blueprint. We > have not tested Gemini Blueprint in Virgo and so it is not currently supported > as it is likely to conflict with the Spring DM extender. > > So I would like to clarify whether this bug really requires Gemini Blueprint > 1.0.0.M1. This is mentioned under "Used runtimes/bundles" but no mention is > made of it under "Steps to Reproduce". Gemini Blueprint is not needed at all, I just used it instead of Spring DM or DS for the bean declaration. Do you want me to change the example bundles to Spring DM? Sorry if that has led to any confusion.
Created attachment 186483 [details] Example bundle using SpringDM instead of Gemini Blueprint
Created attachment 186493 [details] Example aspect bundle (with Require-Bundle header) Changed to match the new Spring-based example bundle, compiled with AspectJ 1.6.6 to avoid incompatible AJ versions, tested and working with Equinox 3.6
Created attachment 186494 [details] Example aspect bundle (with Package-Import header) Changed to match the new Spring-based example bundle, compiled with AspectJ 1.6.6 to avoid incompatible AJ versions, tested and working with Equinox 3.6
(In reply to comment #10) > (In reply to comment #6) > > Please note that Virgo currently embeds and is based on Spring DM 1.2.1 rather > > than Gemini Blueprint. Bug 317943 covers the upgrade to Gemini Blueprint. We > > have not tested Gemini Blueprint in Virgo and so it is not currently supported > > as it is likely to conflict with the Spring DM extender. > > > > So I would like to clarify whether this bug really requires Gemini Blueprint > > 1.0.0.M1. This is mentioned under "Used runtimes/bundles" but no mention is > > made of it under "Steps to Reproduce". > > Gemini Blueprint is not needed at all, I just used it instead of Spring DM or > DS for the bean declaration. Do you want me to change the example bundles to > Spring DM? Sorry if that has led to any confusion. Sorry for the delay in replying. It seems you have already done that, which is useful in narrowing down the problem. Thanks.
I've tried the package import and require bundle variants attached to this bug (mainly due to laziness, I've stuck with the blueprint versions until it becomes obvious that is related to the issue). I even tried my own variant c which uses require-bundle, with a re-export, of the user region bundle since that imports the packages from the kernel region. I see the following log output, or something very similar for the other variants: [2011-01-11 16:58:30.916] fs-watcher <HD0001I> Hot deployer processing 'CREATED' event for file 'org.example.aspect-1.0.0c.jar'. [2011-01-11 16:58:30.942] fs-watcher <DE0000I> Installing bundle 'org.example.aspect' version '1.0.0'. [2011-01-11 16:58:30.957] fs-watcher <DE0001I> Installed bundle 'org.example.aspect' version '1.0.0'. 16:58:30.975 [Spring DM context shutdown thread] INFO System.out - Stop DefaultMyBean [2011-01-11 16:58:30.979] Refresh Packages <DE0010I> Stopping bundle 'org.example.blueprint' version '1.0.0'. [2011-01-11 16:58:30.979] fs-watcher <DE0004I> Starting bundle 'org.example.aspect' version '1.0.0'. [2011-01-11 16:58:30.992] Refresh Packages <DE0011I> Stopped bundle 'org.example.blueprint' version '1.0.0'. [2011-01-11 16:58:30.996] start-signalling-5 <DE0005I> Started bundle 'org.example.aspect' version '1.0.0'. [2011-01-11 16:58:31.073] Refresh Packages <DE0004I> Starting bundle 'org.example.blueprint' version '1.0.0'. [2011-01-11 16:58:31.089] start-signalling-5 <DE0005I> Started bundle 'org.example.blueprint' version '1.0.0'. 16:58:31.165 [SpringOsgiExtenderThread-12] INFO System.out - Start DefaultMyBean There is no evidence of weaving. My suspicion is that the Equinox hook configuration by Virgo is somehow conflicting with the kernel launch property osgi.framework.extensions and rendering the weaving hook inactive. It would be very helpful if you could paste into this bug the output you see under vanilla Equinox.
Created attachment 186543 [details] Console output of Equinox + Virgo + launch.properties
I've attached an archive containing the output of Equinox (for both the SpringDM as well as the blueprint approach) + my Virgo output. I have to admit I didn't check the Virgo Equinox Console before (I am not a big fan of telnet and the Server Console inside Eclipse, missing the nice integration of the Equinox Console with the Eclipse console view ^^) otherwise I would have noticed that Virgo is not loading the two AspectJ bundles (weaving + hook). I just assumed that once I dropped the aspect bundle into the pickup folder and the sample bundles has been updated automatically that weaving has been enabled (except the missing sysout of the aspect bundle it's the exact behaviour I've seen in Equinox before). Sorry for not considering that in the first place.
Hmmm. I have switched to the Spring DM variants to avoid any confusion due to blueprint, but am still struggling to see how all the moving parts should fit together. However, I did an interesting experiment which was to install the package importing aspect bundle and the example bundle in the kernel region and saw the following: 09:00:27.424 [kernel-dm-7] INFO System.out - Hello World from MyAspect 09:00:27.424 [kernel-dm-7] INFO System.out - Hello world from TestClass which matches what you are seeing under vanilla Equinox. So it seems that weaving hook *is* enabled, at least in the kernel region but that some aspect of the kernel/user region isolation is preventing the weaving from happening when the bundles are installed in the user region. Since the user region is being radically redesigned (to use OSGi framework hooks in a single framework rather than the deprecated nested framework support), my next experiment will be to use a prototype of the redesigned user region to see what the behaviour is there.
Good news, bad news... The good news is that it worked with the framework hooks prototype: 09:42:48.321 [region-dm-3] INFO System.out - Hello World from MyAspect 09:42:48.321 [region-dm-3] INFO System.out - Hello world from TestClass However I had to move org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar from the kernel to the user region by placing it in repository/usr instead of lib/kernel and instead of starting it in the kernel launch properties, editing config/org.eclipse.virgo.kernel.userregion.properties to add the following to the end of the initialArtifacts property: , repository:bundle/org.eclipse.equinox.weaving.aspectj The bad news is that the same approach did not work with Virgo 2.1.0 as the bundle org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar was missing an import. I couldn't pin this down and since I've spent my allocation of time on this bug for this sprint, I will stop there. You may like to experiment further in this direction if you have the time and inclination. I am flagging this bug as depending on the framework hooks change after which it is straightforward to get it going, at least with the package importing variant of the aspect bundle.
(In reply to comment #18) > Hmmm. I have switched to the Spring DM variants to avoid any confusion due to > blueprint, but am still struggling to see how all the moving parts should fit > together. I'm sorry but I don't know what you exactly mean with "how all the moving parts should fit together". If you are wondering why I provided two example aspect bundles that's simple: the Equinox aspects quickstart guide mentions the usage of Require-Bundle with re-export, but Package-Import is working fine as well with Equinox (at least for my bundles). When you said that the Require-Bundle header will not work with bundles from the kernel region, I thought it would be best if I provide two aspect bundles with each using another manifest header just to ensure that both are (not) working with Virgo. In case you are wondering why I provided new aspect bundles after I switched the example bundle to the SpringDM-based solution that's because I had a fixed link to the blueprint bundle ("Eclipse-SupplementBundle" in the manifest as well as the "include" element in aop.xml were pointing to the blueprint example bundle and therefore needed to be changed). Sorry if that has lead to some confusion.
(In reply to comment #19) > The bad news is that the same approach did not work with Virgo 2.1.0 as the > bundle org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar was missing an > import. I couldn't pin this down and since I've spent my allocation of time on > this bug for this sprint, I will stop there. You may like to experiment further > in this direction if you have the time and inclination. I may not have enough time for that this week but I will definitely look into that asap and hopefully I will get it working. > I am flagging this bug as depending on the framework hooks change after which > it is straightforward to get it going, at least with the package importing > variant of the aspect bundle. That is great news, thank you very much for looking into that. As I prefer package import over require-bundle any time I am happy with package import ;) Do you think the necessary changes will make it into Virgo 3 (June 2011?) in time? Bye + thanks Frieder
(In reply to comment #20) The moving parts were the various Equinox Aspects and AspectJ bundles and hook rather than your application bundles. Anyway this is less of an issue now I have something working and I wasn't expecting you to explain how the whole lot works. :-)
(In reply to comment #21) > (In reply to comment #19) > > > The bad news is that the same approach did not work with Virgo 2.1.0 as the > > bundle org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar was missing an > > import. I couldn't pin this down and since I've spent my allocation of time on > > this bug for this sprint, I will stop there. You may like to experiment further > > in this direction if you have the time and inclination. > > I may not have enough time for that this week but I will definitely look into > that asap and hopefully I will get it working. Great. Please feed back if you make progress. > > > I am flagging this bug as depending on the framework hooks change after which > > it is straightforward to get it going, at least with the package importing > > variant of the aspect bundle. > > That is great news, thank you very much for looking into that. As I prefer > package import over require-bundle any time I am happy with package import ;) > Do you think the necessary changes will make it into Virgo 3 (June 2011?) in > time? Yes, I'm very keen to get bug 330776 into master. That is my highest priority line item. > > Bye + thanks > Frieder Regards, Glyn
(In reply to comment #19) > The bad news is that the same approach did not work with Virgo 2.1.0 as the > bundle org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503.jar was missing an > import. I got the following exception: [2011-02-08 15:57:22.746] system-artifacts <DE0002E> Installation of bundle 'org.eclipse.equinox.weaving.aspectj' version '1.0.0.v20100503' failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'org.eclipse.equinox.weaving.aspectj' at version '1.0.0.v20100503': Cannot resolve: org.eclipse.equinox.weaving.aspectj Resolver report: An Import-Package could not be resolved. Caused by missing constraint in bundle <org.eclipse.equinox.weaving.aspectj_1.0.0.v20100503> constraint: <Import-Package: org.eclipse.equinox.service.weaving; version="0.0.0"> Next think I tried was to add org.eclipse.equinox.service.weaving;version="0" to the end of the packageImports section in config/org.eclipse.virgo.kernel.userregion.properties but that has led to even more exceptions to be thrown once the user region has been ready(Caused by: java.lang.ClassCastException: org.eclipse.equinox.weaving.aspectj.AspectJWeavingServiceFactory cannot be cast to org.eclipse.equinox.service.weaving.IWeavingServiceFactory). Last thing I tried was to remove org.eclipse.equinox.service.weaving from the packageImports section and add it to the initialArtifacts right before org.eclipse.equinox.weaving.aspectj. This time Virgo starts up w/o any exceptions. Then I first dropped org.example.spring-1.0.0.jar and then org.example.aspect-1.0.0b.jar to the pickup/ folder and I got the following output. [2011-02-08 16:21:07.796] fs-watcher <HD0001I> Hot deployer processing 'CREATED' event for file 'org.example.aspect-1.0.0b.jar'. [2011-02-08 16:21:07.838] fs-watcher <DE0000I> Installing bundle 'org.example.aspect' version '1.0.0'. [2011-02-08 16:21:07.858] fs-watcher <DE0001I> Installed bundle 'org.example.aspect' version '1.0.0'. [2011-02-08 16:21:07.940] fs-watcher <DE0004I> Starting bundle 'org.example.aspect' version '1.0.0'. [2011-02-08 16:21:07.945] start-signalling-2 <DE0005I> Started bundle 'org.example.aspect' version '1.0.0'. [2011-02-08 16:21:07.969] Refresh Packages <DE0010I> Stopping bundle 'org.example.spring' version '1.0.0'. [2011-02-08 16:21:07.974] INFO - Goodbye world from TestClass [2011-02-08 16:21:07.985] Refresh Packages <DE0011I> Stopped bundle 'org.example.spring' version '1.0.0'. [2011-02-08 16:21:08.117] Refresh Packages <DE0004I> Starting bundle 'org.example.spring' version '1.0.0'. [2011-02-08 16:21:08.233] INFO - Hello World from MyAspect [2011-02-08 16:21:08.234] INFO - Hello world from TestClass [2011-02-08 16:21:08.250] start-signalling-2 <DE0005I> Started bundle 'org.example.spring' version '1.0.0'. It looks like AspectJ LTW is working now with Virgo 2.1.0 but I have to run some more tests in the next days/weeks (don't know yet when I will have time for that) to be sure.
Thanks. Keep us posted.
Bug 330776 will go into 3.0.0.M01 and should fix this bug.
(In reply to comment #5) > Created attachment 186247 [details] > Example aspect bundle (with Require-Bundle header) Please can you specify wich version of eclipse and ajdt (or version of aspectj plugins used in compilation) to develop this plugin .
(In reply to comment #28) > Please can you specify wich version of eclipse and ajdt (or version of aspectj > plugins used in compilation) to develop this plugin . I've been using Eclipse 3.6.x, AspectJ 1.6.6 (aspectjtools.jar, aspectjrt.jar) and an ant build file (org.aspectj.tools.ant.taskdefs.Ajc10 if that's of any interest for you). I also had AJDT installed but can't remember what version of the plugin it was. Anyway using the AJDT plugin wasn't an option as it was using a higher AspectJ version than the version provided by the Virgo bundle. This would have led to exceptions because of incompatible versions. As I neither wanted to change my AJDT plugin version nor replace the Virgo bundles I took ant and it was working fine.
(In reply to comment #24) > Last thing I tried was to remove org.eclipse.equinox.service.weaving from the > packageImports section and add it to the initialArtifacts right before > org.eclipse.equinox.weaving.aspectj. This time Virgo starts up w/o any > exceptions. Frieder, Could you please clarify how do you add the missing package 'org.eclipse.equinox.service.weaving' to the initialArtifacts section? Do you add the bundle that exposes it there i.e. 'org.eclipse.equinox.weaving.hook' as this is not working in my case? I verified it's working fine on Virgo 3.0.0 RC by adding it to the packageImports section but I'm trying to get it working on 2.1.0 using your workaround. Thanks!
