Re: [equinox-dev] understanding resolving results

[Martin Lippert]

Hey!

Quick follow-up on this one:
it turned out that the resolver is perfectly correct and that there is indeed a 
subtle difference between those two installs. The orbit bundle for 
“javax.ws.rs” seemed to be the culprit. Both builds got the exact same version 
of the bundle, but when looking inside of the bundle into the manifest, those 
are slightly different. One version adds a version constraint to a 
package-import, the other one not. And the version constraint causes the 
trouble, in combination with a require-bundle on org.eclipse.core.runtime.

What is the best practice these days when using org.eclipse.core.runtime? 
Import the used packages instead to avoid the re-export of system packages (in 
this case javax.xml.annotation.bind)?

Thanks a lot for your help, so much appreciated !!!

Cheers,
-Martin



> Am 12.06.2019 um 15:03 schrieb Thomas Watson :
> 
> What happens if you run with -clean.  Does the bad install still have the 
> uses constraint error?  Before doing so you may want to backup the 
> configuration/ folder so you can get back to the "bad" state.  Equinox caches 
> previous runs wiring state.  When additional bundles are installed they are 
> resolved with the previous wiring state as a starting point.  That means the 
> additional bundles must be able to resolve with the decisions made by the 
> resolver when it resolved the initial set of bundles.  Some cases these 
> decisions from the resolution cache may prevent additional bundles to 
> resolve.  When using -clean this will re-resolve all bundles again, it 
> actually installs all the bundles again from scratch.
>  
> You didn't give much detail on how the two environments got to their current 
> state, so I am not sure if that is what is happening in this case or not.  If 
> running with -clean gets you to a state that has no resolve errors then I 
> would bet something like this is happening.  On the other hand if -clean with 
> one environment cause errors but in the other environment results in success 
> then we do have an anomoly to investigate.  I would start by gathering 
> resolution trace for the two runs.  I would start with the top level resolver 
> trace option (which is pretty noisy, but gets you the most data about what 
> the resolver is doing):
>  
> org.eclipse.osgi/resolver=true
>  
> At this point I assume you know how to enable trace for Eclipse (e.g. specify 
> config.ini option osgi.debug= or use -debug launch option).
> 
> Tom
>  
>  
> - Original message -
> From: Martin Lippert 
> Sent by: equinox-dev-boun...@eclipse.org
> To: Equinox Dev 
> Cc:
> Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving results
> Date: Wed, Jun 12, 2019 5:46 AM
>  
> Hey Mickael,
> 
> > So I am looking for strategies to debug and understand this.
> >
> > Have you tried starting with the `-console` flag to use the OSGi console 
> > and compare the effect of the "start" action on both packages?
> 
> Thanks for the suggestion, not sure I understand this.
> Doing a “start” on a “package” ?!?
> 
> I can see the details about the package-use-contraint violation using the 
> “diag” command and understand the issue, but I am wondering why the resolver 
> decided to not wire it differently, as it is on a different install with the 
> same set of bundles around. There must be a reason for this… :-)
> 
> Cheers,
> -Martin
> 
> 
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev
>  
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] understanding resolving results

[Martin Lippert]

Hey Mickael,

> So I am looking for strategies to debug and understand this.
> 
> Have you tried starting with the `-console` flag to use the OSGi console and 
> compare the effect of the "start" action on both packages?

Thanks for the suggestion, not sure I understand this.
Doing a “start” on a “package” ?!?

I can see the details about the package-use-contraint violation using the 
“diag” command and understand the issue, but I am wondering why the resolver 
decided to not wire it differently, as it is on a different install with the 
same set of bundles around. There must be a reason for this… :-)

Cheers,
-Martin



___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] understanding resolving results

[Martin Lippert]

Hey!

I am trying to understand a somewhat strange setting. I have two Eclipse 
installs with an identical set of bundles. Nevertheless, the dependency 
resolution is different (just fine for one case, 
package-use-constraint-violation in the other case). Therefore I am trying to 
understand why the resolver decides differently in those two cases.

So I am looking for strategies to debug and understand this.

Is there a way to force the resolver to resolve a specific package-import 
against a specific provider of that package to see what happens?
Does it make sense to debug the code directly? If so, what would be a good 
starting point?
Or is there another strategy to find out what is going on?

Thanks a lot for your help!
-Martin


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] how to prevent multithreaded access to bundle activator?

[Martin Lippert]

Hey!

I am debugging and analyzing this issue in m2e at the moment:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=479245#c11

m2e is suffering from a multithreaded access to a bundle activators class. Is 
there a recommended way to prevent that?

Thanks a lot for your help!
-Martin


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] hidpi splash screen possible?

[Martin Lippert]

Hey!

Is it possible to somehow configure a hidpi splash screen image for Eclipse 
products that display nicely on Retina OS X machines, for example?
I’ve seen various activities to support hidpi displays and some issues around 
the launcher, but I haven’t seen any information about how to get a hidpi image 
as a splash screen up and running. Any idea?

Cheers,
-Martin


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Merge of equinox committer groups

[Martin Lippert]

+1

Cheers,
-Martin


> Am 01.03.2016 um 14:49 schrieb Thomas Watson :
> 
> Right now the equinox project has the following sub-projects, each with their 
> own committer groups
> 
> rt.equinox - parent project, no real code here, but it does contain the 
> website
> rt.equinox.framework - where the OSGi framework and Equinox native launcher 
> lives
> rt.equinox.bundles - where everything else is, besides p2
> rt.equinox.p2 - where p2 is
> 
> I plan to request the foundation fold rt.equinox.framework and 
> rt.equinox.bundles into the parent project rt.equinox.  I do not think there 
> is a need to separate committers of the various equinox bundles from 
> committers of the framework/launcher or the website.  I do not plan to 
> request p2 be folded into rt.equinox unless the existing p2 community of 
> committers request that to happen.  p2 is a fairly large codebase so it makes 
> sense to keep it separate if the committers want that.  But the rest of 
> Equinox is not that large and maintaining 3 separate committer groups is not 
> worth it in my opinion.
> 
> Committers, please voice your concerns if you have them.
> 
> Tom
> 
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] issue with optional imports

[Martin Lippert]

Hey!

I have an issue with optionally imported packages and I have no idea what is 
exactly going on or how to diagnose this in more detail.
We have a bundle that defines Import-Package, marked as optional.

org.apache.maven.project;resolution:=optional

There is a bundle (org.eclipse.m2e.maven.runtime) that exports this package and 
everything is wired just fine.
Now I install a new version of m2e and therefore the exporting bundle is 
updated to a new version.

But after the update, the optional package import is not wired again. I would 
expect this to be wired to the new version of that 
org.eclipse.m2e.maven.runtime bundle, but that doesn’t happen. There are no 
other bundles in the system that export this package. A “diag bundleID” (with 
the bundle ID of the importing bundle) doesn’t return anything.

Any idea what might be going on? All this is on Equinox 3.10.1.v20140909-1633 
(Luna SR1, I think).
Or any idea how to investigate this in more detail?

(I already tried to restart Eclipse with -clean, but the result is the same, 
the optional import isn’t wired and I don’t see a potentially package-use 
conflict anywhere)

Thanks a lot for your help!
-Martin



___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Problem exporting packages on Luna

[Martin Lippert]

Hey!

thanks a lot again for the investigation, Tom.

I followed your recommendation and changed the require-bundle dependency on 
org.eclipse.core.runtime with a package-import dependency.
Therefore the issue with the Spring IDE bundles should be solved.

Thanks again a lot for your help!
-Martin




 I have had a look at the jboss issue.  Before going into the long details of 
 my observations I would like a bug report opened against Equinox with the 
 steps to reproduce (what exact version of the VM is used, where to get all 
 the things to install etc).  I have not actually tried to reproduce this.  It 
 seems the change in the equinox resolver to no longer make special preference 
 of packages exported by the system bundle may be contributing to this issue.  
 That old equinox behavior is not in lines with the OSGi specification and 
 does lead to other types of resolution issues.  I deduce this from the 
 following error chain from the resolver:
 
 Unable to resolve resource org.springframework.ide.eclipse.quickfix 
 [osgi.identity; osgi.identity=org.springframework.ide.eclipse.quickfix; 
 type=osgi.bundle; version:Version=3.4.0.201310051539-RELEASE; 
 singleton:=true] because it is exposed to package 'javax.xml.ws' from 
 resources org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; 
 type=osgi.bundle; version:Version=3.10.0.v20140121-0337; 
 singleton:=true] and javax.xml.ws [osgi.identity; 
 osgi.identity=javax.xml.ws; type=osgi.bundle; 
 version:Version=2.1.0.v200902101523] via two dependency chains.
 
 Chain 1:
  org.springframework.ide.eclipse.quickfix [osgi.identity; 
 osgi.identity=org.springframework.ide.eclipse.quickfix; type=osgi.bundle; 
 version:Version=3.4.0.201310051539-RELEASE; singleton:=true]
require: (osgi.wiring.bundle=org.eclipse.core.runtime)
 |
provide: osgi.wiring.bundle: org.eclipse.core.runtime
  org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; 
 type=osgi.bundle; version:Version=3.10.0.v20140121-0337; 
 singleton:=true]
 
 Chain 2:
  org.springframework.ide.eclipse.quickfix [osgi.identity; 
 osgi.identity=org.springframework.ide.eclipse.quickfix; type=osgi.bundle; 
 version:Version=3.4.0.201310051539-RELEASE; singleton:=true]
require: (osgi.wiring.bundle=org.springframework.web)
 |
provide: osgi.wiring.bundle; osgi.wiring.bundle=org.springframework.web; 
 bundle-version:Version=4.0.0.20130829-M3
  org.springframework.web [osgi.identity; 
 osgi.identity=org.springframework.web; type=osgi.bundle; 
 version:Version=4.0.0.20130829-M3]
import: ((osgi.wiring.package=javax.xml.ws)(version=0.0.0))
 |
export: osgi.wiring.package: javax.xml.ws
  javax.xml.ws [osgi.identity; osgi.identity=javax.xml.ws; 
 type=osgi.bundle; version:Version=2.1.0.v200902101523]
 
 This indicates to me that org.springframework.web is exporting some package 
 that uses javax.xm.ws AND org.springframework.web got wired to the 
 javax.xml.ws package exported by the javax.xm.ws bundle.  What is not 
 indicated is the package version of javax.xml.ws, but if this is the orbit 
 bundle (which it seems to be from the version) then the package version is 
 2.1.0.  The resolver prefers packages with a higher version and the 
 system.bundle exports the javax packages with no version (because as of yet 
 nobody knows what version of these packages the various versions of the VM 
 have).  So the resolver picks the higher 2.1.0 version package javax.xml.ws 
 for resolving the org.springframework.web bundle.
 
 org.springframework.ide.eclipse.quickfix is using require-bundle (sigh, here 
 we go) for the org.eclipse.core.runtime bundle, which inturn re-rexports 
 org.eclipse.osgi (yes, re-export is evil!).  In Equinox org.eclipse.osgi is 
 the system.bundle so that means it is exporting javax.xml.ws depending on the 
 Java SE version you are running on.  This is how 
 org.springframework.ide.eclipse.quickfix is getting exposed to the two 
 different versions of javax.xml.ws.  If we had instead preferred the 
 system.bundle export of javax.xml.ws for the Import-Package from 
 org.springframework.web then it is likely this scenario would have resolved 
 OK in Luna.
 
 Another thing that is contributing to this situation is the fact that we 
 changed to doing incremental resolves in Equinox instead of big bang in 
 order to avoid exploding the uses constraint resolve process when we have 
 large sets of bundles [1].  This effectively locks in previous decisions we 
 made when resolving each bundle one at a time.  This is likely why the 
 org.springframework.web bundle gets wired to the higher javax.xml.ws package 
 and locked in without the ability to back off that decision later when we 
 are trying to resolve org.springframework.ide.eclipse.quickfix
 
 At the end of the day there are things the resolve may be able to do to help, 
 but the real issue is the situation the spring bundles have introduced by 
 using require bundle for org.eclipse.core.runtime.  

Re: [equinox-dev] weaving hook and classloading question

[Martin Lippert]

Hey Tom,

 You appear to be using Java 6 which does not allow the use of parallel class 
 loaders [1].  The only reliable way to avoid this kind of deadlock is to use 
 Java 7 so we can avoid the usage of the coarse grained class loader lock.

You are right, the colleague who came across this again used Java 6, so no need 
to bother about this any further, I guess… :-)

Thanks!
-Martin




 
 Tom
 
 [1] 
 http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()
 
 
 
 graycol.gifMartin Lippert ---01/31/2014 05:21:00 AM---Hey! From time to 
 time we are facing a classical classloading deadlock situation when using the 
 Equi
 
 From: Martin Lippert mlipp...@gmail.com
 To:   Equinox Dev equinox-dev@eclipse.org, 
 Date: 01/31/2014 05:21 AM
 Subject:  [equinox-dev] weaving hook and classloading question
 Sent by:  equinox-dev-boun...@eclipse.org
 
 
 
 Hey!
 
 From time to time we are facing a classical classloading deadlock situation 
 when using the Equinox weaving. I know that this is a difficult area and 
 seems to depend heavily on the underlying JDK that Equinox is running on top 
 of, but it keeps bothering me and I am trying to find a way to improve this.
 
 My guess is that the way we do the “additional classloading” in the Equinox 
 weaving hook implementation (for the AspectJ weaving) is involved in this and 
 could be handled more elegant to possibly avoid classloading deadlock 
 situations. We use the “postFindClass” hook to search for the class in 
 additional bundles (in case this “additional dependency” is defined by the 
 way the aspects are woven). It walks through a list of bundles and calls 
 “loadClass”. As you can see below, this is causing the deadlock in the end 
 (as far as I can see).
 
 I attached a thread dump with a deadlock and put a marker on the 
 “postFindClass” calls.
 Do you have any idea how to implement this differently to avoid this deadlock 
 situation?
 
 Thanks a lot in advance!
 -Martin
 
 
 
 
 main:
 waiting to lock monitor 0x7fb32c4ab298 (object 0xd3673308, a 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader),
 which is held by Worker-1
 Worker-1:
 waiting to lock monitor 0x7fb32c035538 (object 0xd34ceaf0, a 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader),
 which is held by main
 
 
 main:
 at 
 org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLoadedClass(ClasspathManager.java:483)
 - waiting to lock 0xd3673308 (a 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
 at 
 org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:462)
 at 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
 at 
 org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
 at 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at org.eclipse.contribution.jdt.IsWovenTester.clinit(IsWovenTester.aj:22)
 at 
 org.eclipse.contribution.jdt.JDTWeavingPlugin.start(JDTWeavingPlugin.java:49)
 at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
 at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
 at 
 org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
 at 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
 at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:478)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
 at 
 org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:109)
 at 
 org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
 at 
 org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
 at 
 org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412

Re: [equinox-dev] Breaking change for Luna Equinox Weaving: IWeavingServiceFactory.createWeavingService takes a BundleDescription

[Martin Lippert]

Hey Stephan!


May I join the party? :)


You are very welcome!!! Would be great to have you on board for this!!!


In https://bugs.eclipse.org/358290 we have a candidate interested
in helping to make the caching service capable to handle multiple
independent weavers.

Martin, could you please share your current implementation as a
common starting point for future experiments? Or should we still
work from master of equinox.weaving and friends?


The current work is going on in the twatson/container branch of the 
rt.equinox.bundles repository. This is the place where we made the 
changes to run that on top of the new framework implementation. And this 
would be the place that I would propose to implement further 
improvements and changes.


The downside is that the implementation there works on the new framework 
only (coming in Luna), but I would like to avoid the need to change two 
implementations simultaneously.



I remember you saying that the cache-key issue shouldn't actually
be an issue, but unfortunately I don't remember your reasoning,
only remember that in my experiment it was a problem :)


To be honest, I don't remember all the details either... ;-)
So we should take a fresh look at this... :-)

The basic design idea was:
- we have a number of weavers
- we have one caching service

The key for the cache is partly generated by the weaver to let the 
weaver decide what should be part of this key. This is important for the 
AspectJ weaving, for example, because the weaving service stays the 
same, but the woven aspects might change over time (new aspect bundles 
installed, old aspect bundles uninstalled). Therefore the weaver 
generates that key.


The caching service hooks into the framework storage and delegates 
classloading bytecode retrieval to the caching service (to avoid 
duplicate bytecode loading from disc).



While currently the OT/J weaver is not based on equinox.weaving
but our own adapter hooks I'd like to use the opportunity while
this topic is in people's heads to help work on a future solution.


Yepp, lets do this.

I think there are two strategies (that come to my mind):

- re-implement the OT/J weaver to use the equinox.weaving service 
interface and therefore plug that into that infrastructure (that also 
handles caching)


- or re-implement both weavers on top of the OSGi weaving hook and 
re-implement the caching to allow it to cache those results.


The first option might be easier to implement (and less work), the 
second one would be a better solution, I think. It would be much more 
aligned with the OSGi spec and Equinox would just provide some 
additional value due to the caching.


The second option would need some kind of additional interface between 
the weavers and the caching (maybe implement or register an additional 
service) so that the caching can retrieve those kind of key 
information from the weavers (and maybe more). But that is just a vague 
idea at the moment.


What do you think?

Cheers,
-Martin



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] IWeavingServiceFactory.createWeavingService takes a BundleDescription

[Martin Lippert]

Hey Tom!

I worked on your branch yesterday and today and got Equinox Weaving to 
work - which is great. So thanks a lot for making all those old hooks 
available!!!


I had to change a few things inside the equinox weaving hook fragment, 
since it made too many implicit assumptions on how and when the 
framework does some bits and pieces. The most notable change that I came 
across was that classloaders seem to be created eagerly now, right after 
the simpleconfigurator ran, but before any other bundles are started.


I changed the way the equinox weaving hook fragment works inside, so 
that is not a real problem. However, I would love to hear your opinion 
on this:


- the weaving.hook fragment doesn't do any weaving or caching itself. It 
just provides the infrastructure bits and pieces. Therefore it creates a 
service tracker to get hold of the concrete weaving (in our case, it is 
this AspectJ weaving implementation).


- but that requires the o.e.e.weaving.aspectj bundle to be installed and 
started right away, before other bundles are doing any classloading (to 
be able to weave a much as possible of the system and to be as 
deterministic as possible)


- at the moment this is done by setting a start level of 4 to that 
bundle and mark it as started (via p2.inf in case it gets installed). In 
my self-hosting workspace, I start it with a start level of 1 at the 
moment. That seems to work to a certain degree. A certain set of bundles 
have been used already for classloading before my weaver bundle 
registered its service.


What do you think is the best way to configure or solve this?

The weaver bundle itself depends on a few other bundles (like the 
aspectj-bundles themselves), so it is obvious that those bundles cannot 
be woven. But everything else should be possible.


Any thoughts?

Cheers,
-Martin


P.S.: I also noticed that I had to set -Dosgi.framework.extensions with 
an absolute path via reference:file: to the weaving hook (in my 
self-hosting setting). Is that correct or am I doing something wrong?




On 15.03.13 19:48, Thomas Watson wrote:

Just to let you know I found a bug in the new container [1].  It was not
informing the class loader hook about a newly created module class
loader.  I suspect this would cause the equinox weaving hooks to not work:

[1] -
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=twatson/containerid=91cf75ccec56a443223b19c6ec14f577d8f0a0fe

Tom



Inactive hide details for Andrew Eisenberg ---03/08/2013 03:34:50
PM---Hi Tom, Thanks for taking a look at this. AJDT is one oAndrew
Eisenberg ---03/08/2013 03:34:50 PM---Hi Tom, Thanks for taking a look
at this.  AJDT is one of the main consumers

From: Andrew Eisenberg and...@eisenberg.as
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 03/08/2013 03:34 PM
Subject: Re: [equinox-dev] IWeavingServiceFactory.createWeavingService
takes a BundleDescription
Sent by: equinox-dev-boun...@eclipse.org





Hi Tom,

Thanks for taking a look at this.  AJDT is one of the main consumers
of org.eclipse.equinox.weaving.hook through the
org.eclipse.equinox.weaving.aspectj bundle.  It looks like you have
also updated the org.eclipse.equinox.weaving.aspectj bundle.  I will
get a chance to try this out next week.  Just to be sure, if I check
out this branch of equinox and drop the osgi bundle into Kepler, will
things hang together?

regards,
Andrew

On Fri, Mar 8, 2013 at 12:57 PM, Thomas Watson tjwat...@us.ibm.com wrote:
  Keep in mind this is a discussion for Luna, not Kepler.  I have been
  spending some time lately around the new framework implementation
based on
  the OSGi R5 generic capability/requirement model.
 
  I was looking at porting the Equinox weaving hooks
  (org.eclipse.equinox.weaving.hook) over to a new Equinox framework
  implementation that is based internally on the generic
  capability/requirement model of the OSGi R5 specification.  This
framework
  implementation no longer is based on the old Equinox resolver API
  (org.eclipse.osgi.service.resolver).  As such the weaving hook
  implementation no longer has access to BundleDescription objects or a
State
  object at runtime.  Instead it would have access to
  org.osgi.framework.wiring.BundleRevsion/BundleWiring objects.
 
  How disruptive would it be to make a breaking API change to
  org.eclipse.equinox.service.weaving.IWeavingServiceFactory to take a
  org.osgi.framework.wiring.BundleRevsion instead of the old
  org.eclipse.osgi.service.resolver.BundleDescription and no longer take a
  org.eclipse.osgi.service.resolver.State?
 
  I noticed the bundle org.eclipse.equinox.weaving.hook exports the package
  org.eclipse.equinox.service.weaving with no version (defaulting to
0.0.0).
  For the next release I suggest we bump this version to 1.0.0 and
indicate a
  breaking change for implementors of
  

Re: [equinox-dev] IWeavingServiceFactory.createWeavingService takes a BundleDescription

[Martin Lippert]

Hey Tom!

I would love to discuss this with you, but unfortunately I will not be 
at EclipseCon (neither Andrew). Andy (Clement) will be, so you should be 
able to chat with him there.


Aside of that I was wondering how you are going to port over the equinox 
weaving hook framework extension to your new framework implementation 
(since it is using all the old equinox framework extension hooks at the 
moment, that I thought wouldn't be there in the new implementation). But 
I think I should take a look at your code before I waste your time here 
with theoretical discussions... ;-)


Anyway, if the equinox weaving hook would work for the new 
implementation, that would be awesome. It is by far not a brilliant 
piece of code, but it would let us reuse the old caching and aspectj 
weaving implementation, I guess. That would save us a lot of time.


Will try to take a look as well, but not before next week.

Cheers,
-Martin


On 12.03.13 13:43, Thomas Watson wrote:

I will be at EclipseCon.  If you and/or Martin are there, perhaps we can
get together to discuss the details there as well.

Tom



Inactive hide details for Andrew Eisenberg ---03/11/2013 06:11:01
PM---Thanks for the advice. I have the workspace set up now aAndrew
Eisenberg ---03/11/2013 06:11:01 PM---Thanks for the advice. I have the
workspace set up now and the hook is being activated.  Unfortunate

From: Andrew Eisenberg and...@eisenberg.as
To: Thomas Watson/Austin/IBM@IBMUS,
Cc: Equinox development mailing list equinox-dev@eclipse.org,
mlipp...@vmware.com
Date: 03/11/2013 06:11 PM
Subject: Re: [equinox-dev] IWeavingServiceFactory.createWeavingService
takes a BundleDescription
Sent by: andrew.eisenb...@gmail.com





Thanks for the advice. I have the workspace set up now and the hook is
being activated.  Unfortunately, the weaving is not happening.  I'll
have to explore a bit more and I'll bring Martin Lippert into the
conversation as well (since he's the original author of Equinox
Weaving).  After we learn a bit more, we'll get back to you.

On Fri, Mar 8, 2013 at 1:48 PM, Thomas Watson _tjwat...@us.ibm.com_
mailto:tjwat...@us.ibm.com wrote:

It is a bit more involved to deploy this into your Kepler instance.
  You have to be running a Kepler instance with a workspace that has
loaded both the org.eclipse.osgi and
org.eclipse.osgi.compatibility.state projects.  Then you have to
export the projects using Export-Plug-in Development-Deployable
plug-ins and fragments and for the destination you have to select
Install into host. Repository:.  This will deploy the new
framework to your running installation and you must then restart
Eclipse.  If all goes well Eclipse will restart successfully on the
new framework.

Note that this is not ready for prime-time, so I suggest you do this
on a Kepler installation that you don't mind blowing up.  I find it
easier to just run Eclipse on the new framework by launching a
self-hosted Eclipse instance from your Eclipse workspace while you
have the org.eclipse.osgi and org.eclipse.osgi.compatibility.state
projects loaded.

Tom



Inactive hide details for Andrew Eisenberg ---03/08/2013 03:34:50
PM---Hi Tom, Thanks for taking a look at this. AJDT is one oAndrew
Eisenberg ---03/08/2013 03:34:50 PM---Hi Tom, Thanks for taking a
look at this.  AJDT is one of the main consumers

From: Andrew Eisenberg _andrew@eisenberg.as_
mailto:and...@eisenberg.as
To: Equinox development mailing list _equinox-dev@eclipse.org_
mailto:equinox-dev@eclipse.org,
Date: 03/08/2013 03:34 PM
Subject: Re: [equinox-dev]
IWeavingServiceFactory.createWeavingService takes a BundleDescription
Sent by: _equinox-dev-bounces@eclipse.org_
mailto:equinox-dev-boun...@eclipse.org





Hi Tom,

Thanks for taking a look at this.  AJDT is one of the main consumers
of org.eclipse.equinox.weaving.hook through the
org.eclipse.equinox.weaving.aspectj bundle.  It looks like you have
also updated the org.eclipse.equinox.weaving.aspectj bundle.  I will
get a chance to try this out next week.  Just to be sure, if I check
out this branch of equinox and drop the osgi bundle into Kepler, will
things hang together?

regards,
Andrew

On Fri, Mar 8, 2013 at 12:57 PM, Thomas Watson
_tjwat...@us.ibm.com_ mailto:tjwat...@us.ibm.com wrote:
  Keep in mind this is a discussion for Luna, not Kepler.  I have been
  spending some time lately around the new framework implementation
based on
  the OSGi R5 generic capability/requirement model.
 
  I was looking at porting the Equinox weaving hooks
  (org.eclipse.equinox.weaving.hook) over to a new Equinox framework
  implementation that is based internally on the generic
  capability

Re: [equinox-dev] Interest in Equinox Weaving

[Martin Lippert]

Hey Tom!

We are still using and consuming the latest bits and pieces from Equinox 
Weaving for AJDT and therefore also many of the Spring tooling projects.


So depending on the general interest it could be an option to move 
Equinox Weaving to the AJDT project after Juno (although I cannot speak 
for the AJDT project here).


-Martin




The Equinox Weaving project has gone rather dormant over the past couple
of releases (Indigo and Juno). The point of this note is to question the
communities interest in the Equinox Weaving project and to request for
help from any of the interested parties. To my knowledge all committers
that have been involved in the Equinox Weaving project have since moved
on to other things and do not have time to devote to maintenance or
future enhancements. Keeping these things around simply because they
have been there in past releases is starting to cause us problems (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=377314).

This is not a threat to remove Equinox Weaving from Juno, but we need to
consider what to do post Juno. Thanks.

Tom



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Lazar Kirchev on rt.equinox.bundles by Martin Lippert

[portal on behalf of Martin Lippert]

Martin Lippert voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] equinox weaving w/ caching and other weavers

[Martin Lippert]

Hey Stephan!

The quick solution here would be to disable the caching service for 
equinox weaving. This can be done by stopping the bundle (or avoid to 
have it auto-started). If the caching bundle is not active, no caching 
happens and everything is freshly woven at startup every time.


The caching service was designed to work with the old equinox weaving 
implementation and is able to invalidate the cache when the weaving 
service produces a different key for the cache. If I remember this 
correctly, this also works with multiple weaving services, but that 
would mean to re-implement the OTDT weaving on top of equinox weaving, 
which doesn't make much sense, I think.


The obvious right step would be to re-implement the caching service to 
work with the new weaving hooks and provide a good caching for those 
weavers (and therefore also multiple weavers). This isn't done yet, I 
think. At least I haven't worked on it - and I guess it is not 
completely trivial. But I just haven't found the time to work on this.


Once this caching service would be in place, we would need to 
re-implement the AspectJ weaver on top of the new weaving hook API, but 
that should not be that complicated.


Just my 2 cents,
Martin



we've been discussing this long time ago, and now some users are finally
bugging me that they want to run OTDT and AJDT in the same eclipse
instance. At a first look both weaving mechanisms (built using the same
adaptor hooks) actually play well together, with minor hickups only,
but after restarting eclipse the class file cache kills the OTDT :)
(Not expecting to see already woven classes we'll add our stuff for
a second time =  boom).

Question is: what would be needed to integrate a second weaver with
the caching infrastructure?

At a first glance I thought I could just check if the class bytes being
loaded already contain our stuff, and if so just skip weaving.
However, I don't know how to check cache validity. It seems there is
no explicit cache invalidation, but rather the cache will just grow
with new directories with new hash-names, right? (No cleanup, ever?)

From that it seems I would have to integrate with the mechanism

for computing fingerprints, but the actual computation of the finger
print is burried inside o.e.e.weaving.aspectj, and this doesn't seem to
be open to add more elements to the finger print.

I saw some activity to migrate the weaving service to the new standard
API. Has it been decided yet, how the caching service will fit into that
picture? Will it have to be redesigned, too?

How about an additional service like
   String getFingerprintAddon(Bundle base)
Then I could register an implementation of the service that encodes
all OT/Equinox bundles that weave into the given base bundle,
I could even add the weaver version into that string,
and the caching service would collect all answers from all these
services for computing the total finger print. What do you think?

Should I file a bug or do you have a better idea?

thanks,
Stephan


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox weaving and OSGI Resolver Hooks

[Martin Lippert]

Hey Tobias!


I am using a org.osgi.framework.hooks.resolver.ResolverHook in order
to create compartments or regions in the OSGI runtime. These
compartments resolve independently of each other.

In conjunction with equinox weaving I have the problem that the
equinox weaving implementation does not consider the ResolverHooks
available in the the runtime when it resolves the supplement bundles.

This leads to the situation that bundles from one compartment are
supplemented with bundles from another compartment which should not
happen in my use case.

Maybe it would make sense to call the available OSGI resolver hooks in
order to check if the possible combinations of supplemented and
supplementer bundles are valid (Maybe this could be implemented in
org.eclipse.equinox.weaving.hooks.SupplementerRegistry.isSupplementerMatching(..)).


I haven't looked at the ResolverHooks in detail yet. Therefore I don't 
know exactly what changes would be necessary, but I think the 
SupplementerRegistry would be the place to look for when the 
compartments or regions should also be respected by the supplementer 
mechanism.


Would you like to take a deeper look at this and maybe provide a patch? 
That would be really great!!! I can help you whenever you need more 
details and/or other help.


Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service Specification (56)

[Martin Lippert]

Hi Alexander!


Ok, everything clear. I will start with the re-implementation of
o.e.e.weaving.aspectj as soon as possible.


This is great!!! Looking forward to it!!!

Cheers,
-Martin




On Thu, May 12, 2011 at 4:23 PM, Thomas Watson tjwat...@us.ibm.com
mailto:tjwat...@us.ibm.com wrote:

Hi, Martin and Alexander.

Martin is correct. The caching aspect of weaving.hook has to be
implemented as an equinox framework extension. I think it would be
great to get the o.e.e.weaving.aspectj to be implemented on top of
the standard OSGi weaving hooks and then provide the performance
improvements (caching etc.) as special extensions to Equinox.

Thanks.

Tom



Inactive hide details for Martin Lippert ---05/12/2011 01:41:59
AM---Hey Alexander!Martin Lippert ---05/12/2011 01:41:59 AM---Hey
Alexander!


From:   
Martin Lippert lipp...@acm.org mailto:lipp...@acm.org

To: 
Equinox development mailing list equinox-dev@eclipse.org
mailto:equinox-dev@eclipse.org

Date:   
05/12/2011 01:41 AM

Subject:
Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service
Specification (56)





Hey Alexander!

  Ok, I now have a much more clearer view on all of the existing logic.
  I agree that going the short way is just a workaround and not a
  upgrade so I will take the long road and will reimplement all bundles
  to use OSGi spec interfaces. Do I correctly understand that
  o.e.e.weaving.hook bundle will therefore be obsoleted completely or
  does it have any extra functions?

I don't think that you can implement the caching part on top of
existing
pure OSGi specifications, but I am not sure.

What I think would be great is:

- having o.e.e.weaving.aspectj to work purely on the OSGi Weaving
hook API.
So people who wanna use aspect weaving can use that on any OSGi runtime
that implements that spec.

- having o.e.e.weaving.hook and o.e.e.weaving.caching to work on
Equinox
only and provide caching for woven bundles, so that people can use that
together with o.e.e.weaving.aspectj, if they wanna have caching for
woven stuff.

I have no idea what that would mean for the implementation of the hook
and the caching, but I would start with adapting o.e.e.weaving.aspectj
to the new OSGi Weaving spec and then would try to reduce the hook
to do
caching only.

Just my thoughts...
Tom, what do you think?

Cheers,
-Martin





 
  On Wed, May 11, 2011 at 11:36 PM, Martin Lippertlipp...@acm.org
mailto:lipp...@acm.org  wrote:
  Hey Alexander!
 
  It wasn't clear to me if you would like to just change the
existing
  implementation to use the new hook or if you would like to
implement a
  completely new aspect weaving mechanism.
 
  So the existing structure of Equinox Weaving is:
 
  - org.eclipse.equinox.weaving.hook
  This uses the basic Equinox hooks to inject a general bytecode
weaving and
  caching mechanism. There is nothing special here for aspect
weaving. This
  hook provides a service interface that other bundles can
implement to
  provide concrete bytecode modifications and a service hook for
caching
  services.
 
  - org.eclipse.equinox.weaving.aspectj
  This implements the service interface from the hook mentioned
above and uses
  the AspectJ weaver to weave aspects into bytecode.
 
  - org.eclipse.equinox.weaving.caching
  This implements the caching service from the hook mentioned
above and
  implements an asynchronous cache storing on the hard drive.
 
  My understanding of the OSGi Weaving specification is that it partly
  implements what the weaving hook mentioned above implemented (so
that
  another bundle can implement a service interface in order to
inject the real
  bytecode modification). So in an ideal world, the
  org.eclipse.equinox.weaving.aspectj bundle would use that
interface in the
  future to realize bytecode weaving instead of the old one from
  o.e.e.weaving.hook. But doing this would also mean that the
caching would no
  longer work for that weaving (because the old o.e.e.weaving.hook
is the glue
  between weaving and caching).
 
  The other way would be to re-implement the o.e.e.weaving.hook
bundle to use
  the new OSGi Weaving spec hook instead of the old
Equinox-specific ones
  while providing the same interface to the outside world as
before (the one
  that the aspectj component uses). That would allow the caching
to work with
  this. But from an design point of view, this wouldn't provide a
big step
  forward, I think.
 
  Just some thoughts...
 
  Cheers,
  -Martin

Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service Specification (56)

[Martin Lippert]

Hey Alexander!


Thanks for your answer, Martin.

I will indeed try to re-implement aspect weaving to comply to the
specification. If I succeed I'll send you my result so you could maybe
just review it and give it a go saving some of your development time..


Any contributions are of course highly welcome. Please let me know when 
you have something working here. Would be glad to take a look.


The CVS resources are at the RT repository:

http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.equinox/weaving/bundles/?root=RT_Project

http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.equinox/weaving/features/?root=RT_Project

Hope that helps!

Are you planning on implementing just pure aspect weaving for AspectJ, 
or are you also looking at the different aspect resolving mechanisms 
(opt-in vs. opt-out) and the caching for woven classes?


Cheers,
-Martin






Therefore could you confirm that these are correct links for latest
source of Equinox Aspects (I got them from the same web site which as
you said is a little outdated):

http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.hook/
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.aspectj/
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.caching/
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.caching.j9/

I was confused by 'equinox-incubator' part. You told me that the
project has graduated to the main SDK so maybe it now resides
somewhere else?

On Tue, May 10, 2011 at 8:28 PM, Martin Lippertlipp...@acm.org  wrote:

Hi Alexander!

Equinox Aspects is not the implementation of the OSGi Weaving Hook Service
Specification. That specification is implemented as part of Equinox 3.7, I
think. So if you use Equinox 3.7, you already have that specification
implementation at hand.

Equinox Aspects (now called Equinox Weaving) has graduated and ins now part
of the Equinox SDK, so regularily updated by nightly builds, etc.
Nevertheless there isn't much activity in this area over the past month, but
its pretty stable and usable.

The relationship between these two things are:
- Equinox Weaving was implemented before the weaving spec came out, to it is
still based on some Equinox-specific hooks deep inside of Equinox and is
currently build mostly to weave aspects into OSGi bundles.
- The OSGi Weaving spec was done to allow all kinds of bytecode weaving on a
general level, so you should be able to re-implement the aspect-weaving part
of Equinox Weaving on top of the new OSGi spec right now. I haven't done
that (haven't found the time), but its on my list.

The web will be updated soon to reflect all this...

Hope this answers your questions!
-Martin






Could you please clarify for me whether the Equinox Aspects is the
implementation of OSGi Weaving Hook Service Specification? The thing
that confuses me is that Equinox Aspects was last update May 1 2009
(according to it's home page
http://www.eclipse.org/equinox/incubator/aspects/index.php) and is
still in incubator state with Milestone 7 as the latest version while
OSGi Weaving Hook Service Specification (56) was added to the
specification starting with version 4.3 which was released about a
month ago.

If the Equinox Aspects really is the implementation of this
specification then what is the current status of this project, what is
it's latest version and is it stable?

If the Equinox Aspects is NOT the implementation of the specification
mentioned then what are the differences between the two and what can
help me in choosing between them.

Thanks in advance...
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] equinox weaving web update

[Martin Lippert]

Hi!

I removed the old Equinox Aspects incubator part from the Equinox web 
and added a small section on Equinox Weaving. The next step for me is a 
write up a new quick start guide for it at the wiki.


Hope these changes are fine with you. Let me know if I should change 
anything.


Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service Specification (56)

[Martin Lippert]

Hi Alexander!

Equinox Aspects is not the implementation of the OSGi Weaving Hook 
Service Specification. That specification is implemented as part of 
Equinox 3.7, I think. So if you use Equinox 3.7, you already have that 
specification implementation at hand.


Equinox Aspects (now called Equinox Weaving) has graduated and ins now 
part of the Equinox SDK, so regularily updated by nightly builds, etc. 
Nevertheless there isn't much activity in this area over the past month, 
but its pretty stable and usable.


The relationship between these two things are:
- Equinox Weaving was implemented before the weaving spec came out, to 
it is still based on some Equinox-specific hooks deep inside of Equinox 
and is currently build mostly to weave aspects into OSGi bundles.
- The OSGi Weaving spec was done to allow all kinds of bytecode weaving 
on a general level, so you should be able to re-implement the 
aspect-weaving part of Equinox Weaving on top of the new OSGi spec right 
now. I haven't done that (haven't found the time), but its on my list.


The web will be updated soon to reflect all this...

Hope this answers your questions!
-Martin






Could you please clarify for me whether the Equinox Aspects is the
implementation of OSGi Weaving Hook Service Specification? The thing
that confuses me is that Equinox Aspects was last update May 1 2009
(according to it's home page
http://www.eclipse.org/equinox/incubator/aspects/index.php) and is
still in incubator state with Milestone 7 as the latest version while
OSGi Weaving Hook Service Specification (56) was added to the
specification starting with version 4.3 which was released about a
month ago.

If the Equinox Aspects really is the implementation of this
specification then what is the current status of this project, what is
it's latest version and is it stable?

If the Equinox Aspects is NOT the implementation of the specification
mentioned then what are the differences between the two and what can
help me in choosing between them.

Thanks in advance...
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Glyn Normington on rt.equinox.bundles by Martin Lippert

[portal on behalf of Martin Lippert]

Martin Lippert voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Borislav Kapukaranov on rt.equinox.bundles by Martin Lippert

[portal on behalf of Martin Lippert]

Martin Lippert voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for John W Ross on rt.equinox.bundles by Martin Lippert

[portal on behalf of Martin Lippert]

Martin Lippert voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Brian de Alwis on rt.equinox.incubator by Martin Lippert

[portal on behalf of Martin Lippert]

Martin Lippert voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Eclipse ViewPart and OSGI Declarative Servicesproblem

[Martin Lippert]

Hi!


Another dependency-injection approach is Spring.  Martin Libbert provided a way 
to bridge extension points w/ spring beans.  See his blog at:
* 
http://martinlippert.blogspot.com/2008/05/dependency-injection-for-extensions.html


The bridge that I built some time ago is now located at:

http://github.com/martinlippert/spring-extension-factory

Cheers,
-Martin






-Original Message-
From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] 
On Behalf Of Neil Bartlett
Sent: Tuesday, November 02, 2010 7:11 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Eclipse ViewPart and OSGI Declarative Servicesproblem

Hi Richard,

This is a rather challenging area, because the lifecycles of services
and extensions are completely unrelated. As you've noticed, creating a
component with DS does not mean it will be used by the extension
registry. Indeed it cannot be, because the extension registry is more
like a factory where new instances are created each time they are
needed.

I created a small framework to help with this kind of thing:
http://github.com/njbartlett/extensions2services. Please be sure to
read the manual (in PDF), because it helps to describe the background
of the problem, even if you decide not to adopt my solution.

Other possible solutions, which all use or include a
dependency-injection approach, are as follows:

1) Eclipse Riena -- however Riena does a lot of other stuff that I
don't really understand
2) Peaberry is based on Guice
3) Eclipse 4.0 (e4) uses dependency injection everywhere, but this
is not much use to you if you are using 3.x.

Regards,
Neil


On Mon, Nov 1, 2010 at 9:17 PM, Richard Catlin
richard.m.cat...@gmail.com  wrote:

I have a ViewPart which depends on an OSGI Declarative Service.

I have it configured properly so that the service is injected into the
ViewPart via a bind method.  I can debug and see that this is working.

The problem I am having is that a new instance of the ViewPart is being
instantiated for viewing and that the instance that was injected is not
being used.

Any help is appreciated.

Thanks.
Richard Catlin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] simpleconfigurator and bundle state

[Martin Lippert]

Hi!

I have a question regarding the simple-configurator. What I would like 
to do is:


- I have an eclipse-based app
- I wanna let the runtime start a bundle by default
- If I stop this bundle, it shouldn't be started again at next startup
- If I start this bundle again, it should be started again at next startup

So what I thought is that this should be the default behavior of the 
OSGi runtime (except the default start of a specific bundle). But I 
observe that the simple configurator is starting the bundle always, if 
this is mentioned in the bundles.info with true. When I stop the bundle 
manually and restart the app, the bundle is started again. This confuses 
me since I expected the OSGi runtime to return the app to the state of 
its last run.


When I switch the setting within the bundles.info to false, everything 
works fine (as I expected from the OSGi point of view) except that the 
bundle is obviously not started at first startup.


Any idea how I can solve this?

Thanks a lot in advance!!!

Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] new website

[Martin Lippert]

Hey Jeff,


Last night I converted over a mess of the Equinox website to the new format.  I tried to 
get all the popular pages. Please do the following:

- Look at the  site and see if there are any things missing or messed up.
- Check that the pages of interest to your work have been converted.  If they 
haven't, convert them (see below) or talk to me.


This is great!!!
I will take a look at the Equinox Weaving part, it deserves some rework 
anyway.


-Martin




Jeff


How to convert. Basically we just changed how the wrapper is setup and how 
sections are delineated.
- Find a file that is converted.  Say equinox/resources.php
- copy the beginning lines down to the midcolumn line
- replace the first part of the old file with the new beginning. NOTE: you will 
want to preserve the pageTitle and pageKeywords variable settings of the old 
file
- grab the last few lines (EOHTML down) from a new file and replace everything after 
the last/div  in the old file.
- save, commit and enjoy

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Cannot get the framework extension, org.eclipse.equinox.weaving.hook, to work in OSGI

[Martin Lippert]

 with the 
system bundle. Here is what my config.ini looks like:

osgi.clean=true
osgi.frameworkClassPath=file\:/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/org.eclipse.osgi_3.4.0.v20080605-1900.jar,file\:/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar
osgi.bundles=org.aspectj.runtime_1.6.1.2008070312, 
org.aspectj.weaver_1.6.1.2008070312,org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar,
 
org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar,org.eclipse.equinox.weaving.demo.hello,
 org.eclipse.equinox.weaving.demo.hello.aspects
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true


All my bundles are in 
/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld. My config.ini is in 
/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/Configuration. I am 
not sure what else I could be doing wrong at this point and I must be close to 
figuring out this problem :)

From: equinox-dev-boun...@eclipse.org [equinox-dev-boun...@eclipse.org] On 
Behalf Of Martin Lippert [lipp...@acm.org]
Sent: Wednesday, June 23, 2010 3:50 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Cannot get the framework extension,  
org.eclipse.equinox.weaving.hook, to work in OSGI

Hi Daniel,

if I remember this correctly you need to put the org.eclipse.osgi bundle
AND the framework extension bundles on the classpath if you start the
runtime the way you do it.

(The exception you mention indicates that the framework extension is not
installed correctly.)

HTH,
-Martin




I have been trying very hard to get the Equinox Aspects Hello World project run 
correctly outside of Eclipse, just using a custom config.ini and the Equinox 
shell. I believe the last thing holding me up is that the weaving.hook fragment 
bundle is not hooking into the system bundle. I have all the files from the 
plugins folder of the Hello World demo in the same folder as my system bundle 
and I have the hello and hello.aspects bundle in the same folder. My config.ini 
is in the ./configuration folder. It is a simple setup and there shouldn't be a 
co-location problems with the hook bundle. I'll post my config.ini below.

Config.ini:

osgi.clean=true
org.aspectj.osgi.verbose=true
eclipse.ignoreApp=true
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
osgi.bundles=org.eclipse.equinox.weaving.demo.hello.aspects, 
org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar, 
org.aspectj.weaver_1.6.1.2008070312, 
org.aspectj.runtime_1.6.1.2008070312, org.eclipse.equinox.weaving.demo.hello
osgi.framework.extensions=org.eclipse.equinox.weaving.hook





I set the framework extension correctly right? Also, here is how I start the 
Equinox shell. If I enter start 3 I get an error, 
java.lang.NoClassDefFoundError: 
org.eclipse.equinox.service.weaving.IWeavingService

djka...@zaius:~/workspaceBlueprint/EquinoxAspectsHellowWorld$ java -jar 
org.eclipse.osgi_3.4.0.v20080605-1900.jar -console 
-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

osgi   ss

Framework is launched.

id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.4.0.v20080605-1900
  Fragments=1
1   RESOLVEDorg.eclipse.equinox.weaving.hook_1.0.0.200808061839
  Master=0
2   RESOLVEDorg.eclipse.equinox.weaving.demo.hello.aspects_1.0.0
3LAZY  org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
4   RESOLVEDorg.aspectj.weaver_1.6.1.2008070312
5   RESOLVEDorg.aspectj.runtime_1.6.1.2008070312
6   RESOLVEDorg.eclipse.equinox.weaving.demo.hello_1.0.0

osgi

This e-mail and any files transmitted with it may be proprietary and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of ITT Corporation. 
The recipient should check this e-mail and any attachments for the presence of 
viruses. ITT accepts no liability for any damage caused by any virus 
transmitted by this e-mail.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Cannot get the framework extension, org.eclipse.equinox.weaving.hook, to work in OSGI

[Martin Lippert]

(BundleLoader.java:385)
 at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
 at 
org.eclipse.equinox.weaving.aspectj.loadtime.OSGiWeavingAdaptor.parseDefinitionFromRequiredBundle(OSGiWeavingAdaptor.java:169)
 at 
org.eclipse.equinox.weaving.aspectj.loadtime.OSGiWeavingAdaptor.parseDefinitionsFromRequiredBundles(OSGiWeavingAdaptor.java:196)
 at 
org.eclipse.equinox.weaving.aspectj.loadtime.OSGiWeavingAdaptor.parseDefinitionsForBundle(OSGiWeavingAdaptor.java:105)
 at 
org.eclipse.equinox.weaving.aspectj.loadtime.OSGiWeavingContext.getDefinitions(OSGiWeavingContext.java:113)
 at 
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:137)
 at 
org.eclipse.equinox.weaving.aspectj.loadtime.OSGiWeavingAdaptor.initialize(OSGiWeavingAdaptor.java:74)
 at 
org.eclipse.equinox.weaving.aspectj.WeavingService.ensureAdaptorInit(WeavingService.java:111)
 at 
org.eclipse.equinox.weaving.aspectj.WeavingService.getKey(WeavingService.java:78)
 at 
org.eclipse.equinox.weaving.adaptors.AspectJAdaptorFactory.getCachingService(AspectJAdaptorFactory.java:141)
 at 
org.eclipse.equinox.weaving.adaptors.AspectJAdaptor.initialize(AspectJAdaptor.java:203)
 at 
org.eclipse.equinox.weaving.adaptors.AspectJAdaptor.findClass(AspectJAdaptor.java:99)
 at 
org.eclipse.equinox.weaving.hooks.AspectJBundleFile.getEntry(AspectJBundleFile.java:44)
 at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:505)
 at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455)
 at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443)
 at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423)
 at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
 at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)
 at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:444)
 at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
 at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
 at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
 at 
org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:313)
 at 
org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
 at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:139)
 at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:980)
 at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
 at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265)
 at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:257)
 at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:257)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150)
 at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:302)
 at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:287)
 at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:223)
 at java.lang.Thread.run(Thread.java:619)

osgi  exit


From: equinox-dev-boun...@eclipse.org [equinox-dev-boun...@eclipse.org] On 
Behalf Of Martin Lippert [lipp...@acm.org]
Sent: Thursday, June 24, 2010 10:25 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Cannot get the framework extension,  
org.eclipse.equinox.weaving.hook, to work in OSGI

Hi Daniel!

Glad to hear that the weaving extension is running now. But the error
you get is strange, since the weaving demo doesn't do anything with XML
or SAX... Do you

Re: [equinox-dev] Cannot get the framework extension, org.eclipse.equinox.weaving.hook, to work in OSGI

[Martin Lippert]

Hi Daniel,

if I remember this correctly you need to put the org.eclipse.osgi bundle 
AND the framework extension bundles on the classpath if you start the 
runtime the way you do it.


(The exception you mention indicates that the framework extension is not 
installed correctly.)


HTH,
-Martin




I have been trying very hard to get the Equinox Aspects Hello World project run 
correctly outside of Eclipse, just using a custom config.ini and the Equinox 
shell. I believe the last thing holding me up is that the weaving.hook fragment 
bundle is not hooking into the system bundle. I have all the files from the 
plugins folder of the Hello World demo in the same folder as my system bundle 
and I have the hello and hello.aspects bundle in the same folder. My config.ini 
is in the ./configuration folder. It is a simple setup and there shouldn't be a 
co-location problems with the hook bundle. I'll post my config.ini below.

Config.ini:

osgi.clean=true
org.aspectj.osgi.verbose=true
eclipse.ignoreApp=true
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
osgi.bundles=org.eclipse.equinox.weaving.demo.hello.aspects, 
org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar, 
org.aspectj.weaver_1.6.1.2008070312, 
org.aspectj.runtime_1.6.1.2008070312, org.eclipse.equinox.weaving.demo.hello
osgi.framework.extensions=org.eclipse.equinox.weaving.hook





I set the framework extension correctly right? Also, here is how I start the 
Equinox shell. If I enter start 3 I get an error, 
java.lang.NoClassDefFoundError: 
org.eclipse.equinox.service.weaving.IWeavingService

djka...@zaius:~/workspaceBlueprint/EquinoxAspectsHellowWorld$ java -jar 
org.eclipse.osgi_3.4.0.v20080605-1900.jar -console 
-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

osgi  ss

Framework is launched.

id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.4.0.v20080605-1900
 Fragments=1
1   RESOLVEDorg.eclipse.equinox.weaving.hook_1.0.0.200808061839
 Master=0
2   RESOLVEDorg.eclipse.equinox.weaving.demo.hello.aspects_1.0.0
3LAZY org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
4   RESOLVEDorg.aspectj.weaver_1.6.1.2008070312
5   RESOLVEDorg.aspectj.runtime_1.6.1.2008070312
6   RESOLVEDorg.eclipse.equinox.weaving.demo.hello_1.0.0

osgi

This e-mail and any files transmitted with it may be proprietary and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of ITT Corporation. 
The recipient should check this e-mail and any attachments for the presence of 
viruses. ITT accepts no liability for any damage caused by any virus 
transmitted by this e-mail.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Cannot get the framework extension, org.eclipse.equinox.weaving.hook, to work in OSGI

[Martin Lippert]

Hi!

I think if you start the OSGi runtime from command line, you need to add 
the framework extensions (the weaving hook on this case) to the 
classpath when you launch the VM. So not just java -jar but java 
-cp. What happens if you try this?


Cheers,
-Martin



On 23.06.10 23:02, Kashtan, Daniel wrote:

Hey Martin,

I just recently found this link, http://wiki.eclipse.org/JDT_weaving_features, 
which I believe details the classpath setup code you are referring to (correct 
me if I am wrong). I unfortunately still can't get the hook working with the 
system bundle. Here is what my config.ini looks like:

osgi.clean=true
osgi.frameworkClassPath=file\:/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/org.eclipse.osgi_3.4.0.v20080605-1900.jar,file\:/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar
osgi.bundles=org.aspectj.runtime_1.6.1.2008070312, 
org.aspectj.weaver_1.6.1.2008070312,org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar,
 
org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar,org.eclipse.equinox.weaving.demo.hello,
 org.eclipse.equinox.weaving.demo.hello.aspects
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true


All my bundles are in 
/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld. My config.ini is in 
/home/djkasht/workspaceBlueprint/EquinoxAspectsHellowWorld/Configuration. I am 
not sure what else I could be doing wrong at this point and I must be close to 
figuring out this problem :)

From: equinox-dev-boun...@eclipse.org [equinox-dev-boun...@eclipse.org] On 
Behalf Of Martin Lippert [lipp...@acm.org]
Sent: Wednesday, June 23, 2010 3:50 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Cannot get the framework extension,  
org.eclipse.equinox.weaving.hook, to work in OSGI

Hi Daniel,

if I remember this correctly you need to put the org.eclipse.osgi bundle
AND the framework extension bundles on the classpath if you start the
runtime the way you do it.

(The exception you mention indicates that the framework extension is not
installed correctly.)

HTH,
-Martin




I have been trying very hard to get the Equinox Aspects Hello World project run 
correctly outside of Eclipse, just using a custom config.ini and the Equinox 
shell. I believe the last thing holding me up is that the weaving.hook fragment 
bundle is not hooking into the system bundle. I have all the files from the 
plugins folder of the Hello World demo in the same folder as my system bundle 
and I have the hello and hello.aspects bundle in the same folder. My config.ini 
is in the ./configuration folder. It is a simple setup and there shouldn't be a 
co-location problems with the hook bundle. I'll post my config.ini below.

Config.ini:

osgi.clean=true
org.aspectj.osgi.verbose=true
eclipse.ignoreApp=true
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
osgi.bundles=org.eclipse.equinox.weaving.demo.hello.aspects, 
org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar, 
org.aspectj.weaver_1.6.1.2008070312, 
org.aspectj.runtime_1.6.1.2008070312, org.eclipse.equinox.weaving.demo.hello
osgi.framework.extensions=org.eclipse.equinox.weaving.hook





I set the framework extension correctly right? Also, here is how I start the 
Equinox shell. If I enter start 3 I get an error, 
java.lang.NoClassDefFoundError: 
org.eclipse.equinox.service.weaving.IWeavingService

djka...@zaius:~/workspaceBlueprint/EquinoxAspectsHellowWorld$ java -jar 
org.eclipse.osgi_3.4.0.v20080605-1900.jar -console 
-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

osgi   ss

Framework is launched.

id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.4.0.v20080605-1900
  Fragments=1
1   RESOLVEDorg.eclipse.equinox.weaving.hook_1.0.0.200808061839
  Master=0
2   RESOLVEDorg.eclipse.equinox.weaving.demo.hello.aspects_1.0.0
3LAZY  org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
4   RESOLVEDorg.aspectj.weaver_1.6.1.2008070312
5   RESOLVEDorg.aspectj.runtime_1.6.1.2008070312
6   RESOLVEDorg.eclipse.equinox.weaving.demo.hello_1.0.0

osgi

This e-mail and any files transmitted with it may be proprietary and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of ITT Corporation. 
The recipient should check this e-mail and any attachments for the presence of 
viruses. ITT accepts no liability for any damage caused by any virus 
transmitted by this e-mail.
___
equinox-dev mailing list

Re: AW: [equinox-dev] Question on programatic close of the runtime

[Martin Lippert]

Hi!

You can just go to:

https://dev.eclipse.org/mailman/listinfo/equinox-dev

to unsubscribe from the list.

HTH,
Martin


On 12.03.10 21:30, cpint...@pt.lu wrote:


Hello,
Please stop sending me emails!
Take me out of your mailing list.
p...@email.lu



Thomas Watson tjwat...@us.ibm.com a écrit :



Why are you using the -console option? Seems like you would not really
want something on a cluster to be running in console mode. I am wondering
who actually would run commands on this console. I suggest you look at
the
org.eclipse.osgi.framework.console.ConsoleSession service in 3.6 if you
need a remote console for which you want more control over. When you
register a ConsoleSession service a new console will be started for your
ConsoleSession. You will have control over what provides the input and
output for the console session (use System.in/out, use a socket,
provide a
web UI, provide a console RCP view etc.). Then when you want the session
to end you simply unregister your ConsoleSession. If a bundle provides
the
console session service then the session will automatically get
cleaned up
when stopping the system bundle because all bundles will be stopped which
causes all services registered by bundles to be unregistered.

Unfortunately the built-in console session that gets used with the
-console
option does not automatically close when the framework is shutdown. This
is because we have some support in the console for running commands even
after the framework has shutdown and we leave this session open for that
purpose. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=279562 for
more
details.

Tom




|
| From: |
|
--|

|daniel.stu...@empolis.com |
--|

|
| To: |
|
--|

|equinox-dev@eclipse.org |
--|

|
| Date: |
|
--|

|03/12/2010 11:15 AM |
--|

|
| Subject: |
|
--|

|AW: [equinox-dev] Question on programatic close of the runtime |
--|






Hi all,

our application (BTW: we are talking about SMILA) is a backend server,
with
instances running on a cluster. What do you suggest to remotely shutdown
the OSGi instances on each cluster node?

We cannot expect an administrator to log on every machine and to exit the
OSGI console by typing close.

Therefore I had the idea to provide this functionality via HTTP. So
it's an
external call that stops bundle zero and after a configurable timeout
calls
System.exit() (hopefully giving the runtime enough time to savely stop
all
bundles). So the System.exit() is done on purpose by an administrator.

One way of connecting remotely would be to use telnet and then send a
close
command to the OSGi console. But this is cumbersome. Is this safer than
my approach as after Framework.close() this does also call
System.exit() ?

Bye,
Daniel


-Ursprüngliche Nachricht-
Von: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] Im Auftrag von Neil Bartlett
Gesendet: Freitag, 12. März 2010 17:54
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Question on programatic close of the runtime

Tim,

I agree but it's a matter of who is responsible for doing this. The
launcher code that created the framework and started it should be
responsible for shutting down the VM, after calling
Framework.waitForStop(). If a bundle calls System.exit() then it is
assuming too much about the environment in which it is deployed.

Neil

On Fri, Mar 12, 2010 at 4:47 PM, Tim Diekmann tdiek...@tibco.com wrote:

Hi,

while calling stop() on the system bundle is the correct and recommended

approach, it is not always sufficient in production environments.


The framework will only end if the main() method that started it runs
out

or someone calls System.exit(). However, for the main method to end, all
non-daemon 

[equinox-dev] +1 for David Lavin on rt.equinox.incubator

[portal on behalf of Martin Lippert]

+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Scott Lewis on rt.equinox.incubator

[portal on behalf of Martin Lippert]

+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] optional dependencies for weaving.aspectj

[Martin Lippert]

Hi!

I am observing a problem with the optional dependencies for 
org.eclipse.equinox.weaving.aspectj. We made the dependencies to some 
aspectj stuff optional (which is good and works fine). But I also added 
a version constraint to the import (which should be the minimal 
version). But since the optional flag is set, the runtime doesn't wire 
this optional dependency to available higher versions of the package.


Any idea how to resolve this?

Thanks!!!

Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] optional dependencies for weaving.aspectj

[Martin Lippert]

I expected exactly what you describe, but observed something else... :-(

What I observe is:

- org.aspectj.weaver package is available in version 1.6.4 (its the only 
available version)
- org.eclipse.equinox.weaving.aspectj defines an import on 
org.aspectj.weaver for the minimum version 1.6.3


What seems to happen is:

- if there *IS NO* optional flag for the import, 
org.eclipse.equinox.weaving.aspectj gets wired to version 1.6.4

(correct)

- if there *IS* an optional flag for the import, 
org.eclipse.equinox.weaving.aspecjt doesn't get wired to 
org.aspectj.weaver at all, even that there is version 1.6.4 available

(not correct, I think)

I will check again, but this seems to be what I observe...

-Martin


Thomas Watson wrote:

I'm not sure I understand why the fact that these constraints are optional
is causing you an issue.  I would expect the same behavior for non-optional
imports.

If a bundle imports a lower version of a package and gets wired to that
lower version, then later a new bundle is installed which exports a higher
version of the package, I would not expect the importer to automatically
get wired to the new package.  This should only happen if you uninstall the
old version of the exporter and refresh the importing bundle or you refresh
the importing bundle to force it to re-resolve.  At that point I would
expect it to get wired to the higher version regardless of if the import
was optional or not.

Tom




|
| From:  |
|
  
--|
  |Martin Lippert lipp...@acm.org 
 |
  
--|
|
| To:|
|
  
--|
  |Equinox Project equinox-dev@eclipse.org
 |
  
--|
|
| Date:  |
|
  
--|
  |09/15/2009 11:52 AM  
 |
  
--|
|
| Subject:   |
|
  
--|
  |[equinox-dev] optional dependencies for weaving.aspectj  
 |
  
--|





Hi!

I am observing a problem with the optional dependencies for
org.eclipse.equinox.weaving.aspectj. We made the dependencies to some
aspectj stuff optional (which is good and works fine). But I also added
a version constraint to the import (which should be the minimal
version). But since the optional flag is set, the runtime doesn't wire
this optional dependency to available higher versions of the package.

Any idea how to resolve this?

Thanks!!!

Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev






___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Equinox Aspects Move

[Martin Lippert]

Hi!

Just an update on the graduation of Equinox Aspects: After the 
successful graduation review the core bundles of Equinox Aspects are now 
moved to the new location:


/cvsroot/rt/org.eclipse.equinox/weaving/bundles

The moved projects/bundles are:

org.eclipse.equinox.weaving.hook
org.eclipse.equinox.weaving.aspectj
org.eclipse.equinox.weaving.caching
org.eclipse.equinox.weaving.caching.j9

Please update your settings, if you refer to these projects from CVS.

Cheers,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] adviceexecution and annotations in equinox aspects

[Martin Lippert]

Hi!


I'd like to know if Equinox Aspects suports adviceexecution and
annotations I've made a simple adviceexecution to advise any advice and
my application got several errors during execution and in the end the
adviceexecution didn't advise


You should be able to use all the AspectJ features with Equinox Aspects. 
If something doesn't work with Equinox Aspects that works with AspectJ, 
it looks like a bug.


In that case would you submit a bug report to bugzilla? And if you have 
(or can produce) a small test project to reproduce the problem, that 
would be really good.


-Martin



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Re: New Equinox Team meeting time.

[Martin Lippert]

Hi Tom!


At the Equinox call today we decided that we should move the Equinox team
meeting to a more appropriate time for our European team members from
Prosyst and Equinox Weaving.  I have put together a doodle poll to help us
in selecting a new weekly time for the Equinox team meeting.  Please use
the doodle poll at http://www.doodle.com/5z99wr96ctqxkd2u to cast your vote
on the times that work for you.


I added my votes to the poll, but I travel a lot and will not be able to 
make it for the call every week. So don't put too much attention to my 
votes... ;-)


-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] AutoStarting Bundles in a Feature Definition

[Martin Lippert]

Hi!

This is an example that we use for automatically start some of the 
Equinox Aspects bundles after p2 installation:


instructions.configure = \
setStartLevel(startLevel:4); \
markStarted(started: true);

HTH,
-Martin




cwolfing wrote:

Hello - Is there a way to use the p2.inf configuration on a feature to
indicate which bundles to mark as started?

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Framework Checkout problem

[Martin Lippert]

Hi!

Seems like you are looking at the old repository location. All the Equinox
projects were moved to the runtime project: cvsroot/rt. Check out from
that location, should work better.

HTH,
-Martin


 Hi,

 Past few days, I had been trying to check out the Equinox Framework
 Project
 : org.eclipse.osgi from CVS repo.

 The tree shows many folders but when I checkout I get only one 'readme'
 file
 checked out.

 I used Eclipse CVS and checked 'org.eclipse.osgi' as New project in
 Eclipse.
 It did not work out.
 Then I used 'Tortoise CVS' after fetching the list from this location : :
 pserver:anonym...@dev.eclipse.org/cvsroot/eclipse , I checked out
 'org.eclipse.osgi'.
 What I noticed using tortoise CVS was that, all the subfolders in
 'org.eclipse.osgi' do come up when being checked out, but after process is
 over they are deleted by themselves.

 Am I doing anything wrong here ? Please help !!
 I was thinking repo server might be down. But its still not working. I
 could
 check out other projects via both Eclipse and Tortoise CVS.



 Regards,
 à€#65533;mit à€žà¥#65533;rana (Amit)

 My Blog: http://blog.suranaamit.com/
 GMF Documentation : http://gmfdoc.suranaamit.com/
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Version problems with Equinox aspects 1.0M6

[Martin Lippert]

Hi Jens!

Do you think there is any chance for me to get this reproduced somehow? 
Any idea?


Cheers,
-Martin


Jens Goldhammer wrote:

Hello Martin,

Our rcp app is based on features and the problem is that the aspectj weaver
bundle which is installed, could not be resolved during the build. But I
don´t know why. The versions of the bundles are synchronized during the
build. This works for all other plugins, but indeed not for aspectj. 


So, I had to revert to an older version for a first fix because we have a
red lava lamp since 2 days. :-(

Bye,
Jens



Martin Lippert wrote:

Hi Jens!


I have downloaded the new version of Equinox Aspects 1.0M6. I have seen
that
it has a version dependency on at least version 1.6.2 of the aspectj
weaver
package.
(http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-news-1.0-M6.html)

But I think it is not correctly defined in the MANIFEST.MF because I am
getting the following error while building the product on our Hudson CI
Server...
Yes, the version dependency is new, but I am not sure what the problem 
with your CI server could be. EA builds nicely from my IDE... Hm... Do 
you have any more details on the problem?


-Martin



Build Script Failure:
 [java] generateScript:
 [java] [eclipse.buildScript] Some inter-plug-in dependencies have
not
been satisfied.
 [java] [eclipse.buildScript] Bundle
org.eclipse.equinox.weaving.aspectj:
 [java] [eclipse.buildScript]   Unsatisfied import package
org.aspectj.weaver_1.6.2.
 [java] [eclipse.buildScript]   Unsatisfied import package
org.aspectj.weaver.loadtime_1.6.2.
 [java] [eclipse.buildScript]   Unsatisfied import package
org.aspectj.weaver.loadtime.definition_1.6.2.
 [java] [eclipse.buildScript]   Unsatisfied import package
org.aspectj.weaver.tools_1.6.2.

Can you help me, please?
Thanks,
Jens

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How do I add imports?

[Martin Lippert]

Hi!


Hi sorry again, but adding it as a jar or adding it as a plugin?
Maybe I got lost but this is for users of Equinox or developers who
contribute to Equinox?


This mailing list of mostly for contributors, the newsgroup is the 
primary address for users.


In OSGi, there is something we call a BUNDLE, which is a jar file with a 
manifest and specific entries in the manifest. A plugin (in the sense of 
Eclipse) is the same. Did you take a look at some introductory OSGi 
tutorial stuff?


-Martin







Thanks!


Today's Topics:

   1. Re: How do I add imports? (Martin Lippert)
   


--

Message: 1
Date: Thu, 19 Mar 2009 20:57:42 +0100
From: Martin Lippert lipp...@acm.org
Subject: Re: [equinox-dev] How do I add imports?
To: Equinox development mailing list equinox-dev@eclipse.org
Message-ID: 49c2a3b6.1070...@acm.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi!


I've got the Plugin projects started, but when I add APIs, I shouldn't
use Add Jars in the Build Path right?

So eg if I need log4j, how do I add it to the project?


The way to go is to catch up an OSGi bundle of log4j (take a look at the

Orbit project, the Spring Enterprise Bundle Repository or maybe your 
favorite project does already provide the jar file as OSGi bundle), add 
it to your target platform, add an import-package definition to your 
manifest and thats it.


Anyway, those questions should be asked via the newsgroup, I think.

HTH,
Martin


 


Meanwhile I've only found out how to add at the osgi prompt -

install

URL...

 


Thanks!


NOTICE - This message and any attached files may contain information

that is confidential and/or subject of legal privilege intended only for
use by the intended recipient. If you are not the intended recipient or
the person responsible for delivering the message to the intended
recipient, be advised that you have received this message in error and
that any dissemination, copying or use of this message or attachment is
strictly forbidden, as is the disclosure of the information therein.  If
you have received this message in error please notify the sender
immediately and delete the message.







___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



--

Message: 2
Date: Fri, 20 Mar 2009 08:54:46 +0100
From: Peter Kriens peter.kri...@aqute.biz
Subject: [equinox-dev] OSGi DevCon 2009 with Jazoon in Zurich June 22,
Call for Speakers
To: Equinox development mailing list equinox-dev@eclipse.org
Message-ID: e61d78eb-d193-4377-b1b3-bbce80cd8...@aqute.biz
Content-Type: text/plain; charset=us-ascii

The OSGi Alliance is organizing a one day OSGi DevCon together with  
Jazoon in Zurich (June 22). It will be a one day event. Details can be  
found at http://www.osgi.org/DevConEurope2009/HomePage


We are currently looking for speakers on this day. Being subscribed to  
the Equinox developer list is bound to give you lots of subjects to  
talk to! If you are interested, please sign up at

http://www.osgi.org/DevConEurope2009/CFP

Looking forward to hear from you, kind regards,

Peter Kriens
-- next part --
An HTML attachment was scrubbed...
URL:
https://dev.eclipse.org/mailman/private/equinox-dev/attachments/20090320
/37fac06d/attachment.html

--

Message: 3
Date: Fri, 20 Mar 2009 10:31:13 -0400
From: Andrew Niefer anie...@ca.ibm.com
Subject: Re: [equinox-dev] Re: 3.5M6 missing eclipse directory
To: Equinox development mailing list equinox-dev@eclipse.org
Message-ID:

of2d60238e.8d1c4a42-on8525757f.004ee700-8525757f.004fb...@ca.ibm.com
Content-Type: text/plain; charset=us-ascii

Skipped content of type multipart/alternative-- next part
--
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url :
https://dev.eclipse.org/mailman/private/equinox-dev/attachments/20090320
/6b57d2f1/attachment.gif
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url :
https://dev.eclipse.org/mailman/private/equinox-dev/attachments/20090320
/6b57d2f1/attachment-0001.gif
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url :
https://dev.eclipse.org/mailman/private/equinox-dev/attachments/20090320
/6b57d2f1/attachment-0002.gif
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url :
https://dev.eclipse.org/mailman/private/equinox-dev/attachments/20090320
/6b57d2f1/attachment-0003.gif
-- next

Re: [equinox-dev] [org.eclipse.equinox.weaving.hook] info removing supplementer

[Martin Lippert]

Hi Steven!

I looked at your example and it looks good, from my point of view. It 
seems to be a question of how you launch your app. Do you launch an 
Eclipse Application from your IDE? In that case you should add the 
simpleconfigurator bundle to your config.ini setting:


osgi.bundles=org.eclipse.equinox.simpleconfigura...@1\:start, 
org.eclipse.equinox.weaving.aspe...@1\:start


I tried that and it works pretty fine. Maybe you should also set clean 
configuration area before launching to be sure to run within a clean 
configuration.


HTH,
-Martin



steven wrote:

hi martin,

that's right, my aspect is not woven.
I attached a sample workspace.


thanks for your support!!

steven

On Mar 6, 2009, at 12:12 PM, Martin Lippert wrote:


Hi Steven!

The message removing supplementer looks indeed strange, but some 
weaving seems to take place. But that seems not like weaving from your 
aspect, right?


Could you send me a small example workspace to tryou your setting?

-Martin




I am trying to hook into an eclipse plugin. I am using the 
HelloAspect.aj from the Hello World! Demo.

My config.ini:
osgi.bundles=org.eclipse.equinox.weaving.aspe...@1\:start
osgi.bundles.defaultStartLevel=4
osgi.framework=org.eclipse.osgi
osgi.configuration.cascaded=false
osgi.splashPath=platform:/base/plugins/org.eclipse.platform
org.eclipse.update.reconcile=false
# AOSGi
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true
The plugin that I am trying to hook into, is an eclipse ui sample 
plugin.
As in the hello world demo, HelloAspect.aj hooks into the execution 
of the Activator's start() method.

when starting a runtime workbench I get the following output:
[org.eclipse.equinox.weaving.hook] info adding AspectJ hooks ...
[org.eclipse.equinox.weaving.hook] info removing supplementer 
org.eclipse.equinox.weaving.demo.hello.aspects
[org.eclipse.equinox.weaving.aspectj] info Starting AspectJ weaving 
service ...
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 
'org.eclipse.jdt.ui'
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 
'org.eclipse.jdt.core'
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.core.WorkingCopyOwner' (WorkingCopyOwner.java:140) 
advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.core.WorkingCopyOwner' (WorkingCopyOwner.java:187) 
advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.JavaModelManager' 
(JavaModelManager.java:2140) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'method-execution(void 
org.eclipse.jdt.internal.core.Openable.codeComplete(org.eclipse.jdt.internal.compiler.env.ICompilationUnit, 
org.eclipse.jdt.internal.compiler.env.ICompilationUnit, int, 
org.eclipse.jdt.core.CompletionRequestor, 
org.eclipse.jdt.core.WorkingCopyOwner, 
org.eclipse.jdt.core.ITypeRoot))' in Type 
'org.eclipse.jdt.internal.core.Openable' (Openable.java:105) advised 
by around advice from 
'org.eclipse.contribution.jdt.itdawareness.ITDAwarenessAspect' 
(ITDAwarenessAspect.aj:255)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:574) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:873) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo

Re: [equinox-dev] [org.eclipse.equinox.weaving.hook] info removing supplementer

[Martin Lippert]

Hi Steven!

The message removing supplementer looks indeed strange, but some 
weaving seems to take place. But that seems not like weaving from your 
aspect, right?


Could you send me a small example workspace to tryou your setting?

-Martin




I am trying to hook into an eclipse plugin. I am using the 
HelloAspect.aj from the Hello World! Demo.

My config.ini:

osgi.bundles=org.eclipse.equinox.weaving.aspe...@1\:start
osgi.bundles.defaultStartLevel=4
osgi.framework=org.eclipse.osgi
osgi.configuration.cascaded=false
osgi.splashPath=platform:/base/plugins/org.eclipse.platform
org.eclipse.update.reconcile=false

# AOSGi
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true

The plugin that I am trying to hook into, is an eclipse ui sample plugin.
As in the hello world demo, HelloAspect.aj hooks into the execution of 
the Activator's start() method.

when starting a runtime workbench I get the following output:

[org.eclipse.equinox.weaving.hook] info adding AspectJ hooks ...
[org.eclipse.equinox.weaving.hook] info removing supplementer 
org.eclipse.equinox.weaving.demo.hello.aspects
[org.eclipse.equinox.weaving.aspectj] info Starting AspectJ weaving 
service ...
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 
'org.eclipse.jdt.ui'
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 
'org.eclipse.jdt.core'
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.core.WorkingCopyOwner' (WorkingCopyOwner.java:140) 
advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.core.WorkingCopyOwner' (WorkingCopyOwner.java:187) 
advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.JavaModelManager' 
(JavaModelManager.java:2140) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'method-execution(void 
org.eclipse.jdt.internal.core.Openable.codeComplete(org.eclipse.jdt.internal.compiler.env.ICompilationUnit, 
org.eclipse.jdt.internal.compiler.env.ICompilationUnit, int, 
org.eclipse.jdt.core.CompletionRequestor, 
org.eclipse.jdt.core.WorkingCopyOwner, org.eclipse.jdt.core.ITypeRoot))' 
in Type 'org.eclipse.jdt.internal.core.Openable' (Openable.java:105) 
advised by around advice from 
'org.eclipse.contribution.jdt.itdawareness.ITDAwarenessAspect' 
(ITDAwarenessAspect.aj:255)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:574) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:873) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:964) advised by around advice from 
'org.eclipse.contribution.jdt.cuprovider.CompilationUnitProviderAspect' 
(CompilationUnitProviderAspect.aj:38)
[org.eclipse.jdt.core] weaveinfo Join point 'constructor-call(void 
org.eclipse.jdt.internal.core.CompilationUnit.init(org.eclipse.jdt.internal.core.PackageFragment, 
java.lang.String, org.eclipse.jdt.core.WorkingCopyOwner))' in Type 
'org.eclipse.jdt.internal.core.CompilationUnit' 
(CompilationUnit.java:1120) advised by 

Re: [equinox-dev] LinkageError when using after returning aspect in AspectJ for OSGI

[Martin Lippert]

Hi Dirk!


with the latest version it works great ! Really nice.


Great to hear!


I didn't checked the version of the plug-in's used  in  the demo.


Np...

Cheers,
-Martin





Tx.

Martin Lippert wrote:

Hi Dirk!

I tried your example with the current build and it seems to work fine. 
Could you try your setting with the latest build of Equinox Aspects in 
order to verify this? (from your description I guess that you are 
using the older version that is part of the examples target project...)


HTH,
-Martin



Dirk Jacobs wrote:

Hi,

Tx for helping me out.

The included code is a variation of the demo of Heiko so you should 
add the target that's part of the demo.

The aspect is now written in .java/Annotation format
If you comment the line : initializable.initialize(); in 
TestAspect.java , you will see that everything works.

Otherwise you get the error :

Caused by: java.lang.LinkageError: loader constraint violation: 
loader (instance of 
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) previously 
initiated loading for a different type with name 
org/eclipse/equinox/weaving/demo/hello/internal/Initializable
  at 
org.eclipse.equinox.weaving.hello.aspects.TestAspect.anotherConstruct(TestAspect.java:16) 

  at 
org.eclipse.equinox.weaving.demo.hello.internal.Activator.start(Activator.java:21) 

  at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009) 


  at java.security.AccessController.doPrivileged(Native Method)
  at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003) 


  ... 14 more

Thanks again,


Dirk


Martin Lippert wrote:

Hi Dirk!

Do you have a small ready-to-use project that you can send me as 
zip? To me it looks like I should take a closer look into what 
happens here.


Thanks!
-Martin



Dirk Jacobs wrote:

I created an aspect bundle (a variation of the demo)

I want to have an initialize method called after a constructor has 
finished.


The aspect is triggered, but when I want to execute the initialize 
method, I got a linkage error.

All classes are public and the package is exported.

The aspect is as follows :
package org.eclipse.equinox.weaving.hello.aspects;
import org.aspectj.lang.annotation.AfterReturning;
import org.eclipse.equinox.weaving.demo.hello.internal.Initializable;

public aspect HelloAspect3 {   after() 
returning(Initializable initializable) : 
call(org.eclipse.equinox.weaving.demo.hello.internal.Initializable+.new(..)) 
{

   if( initializable != null) {
   System.out.println(After Initializable Constructor);
   initializable.initialize();
   } else {
   System.out.println(After Non-Initializable Constructor);
   }
   }
}

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] LinkageError when using after returning aspect in AspectJ for OSGI

[Martin Lippert]

Hi Dirk!

I tried your example with the current build and it seems to work fine. 
Could you try your setting with the latest build of Equinox Aspects in 
order to verify this? (from your description I guess that you are using 
the older version that is part of the examples target project...)


HTH,
-Martin



Dirk Jacobs wrote:

Hi,

Tx for helping me out.

The included code is a variation of the demo of Heiko so you should add 
the target that's part of the demo.

The aspect is now written in .java/Annotation format
If you comment the line : initializable.initialize(); in TestAspect.java 
, you will see that everything works.

Otherwise you get the error :

Caused by: java.lang.LinkageError: loader constraint violation: loader 
(instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) 
previously initiated loading for a different type with name 
org/eclipse/equinox/weaving/demo/hello/internal/Initializable
  at 
org.eclipse.equinox.weaving.hello.aspects.TestAspect.anotherConstruct(TestAspect.java:16) 

  at 
org.eclipse.equinox.weaving.demo.hello.internal.Activator.start(Activator.java:21) 

  at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009) 


  at java.security.AccessController.doPrivileged(Native Method)
  at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003) 


  ... 14 more

Thanks again,


Dirk


Martin Lippert wrote:

Hi Dirk!

Do you have a small ready-to-use project that you can send me as zip? 
To me it looks like I should take a closer look into what happens here.


Thanks!
-Martin



Dirk Jacobs wrote:

I created an aspect bundle (a variation of the demo)

I want to have an initialize method called after a constructor has 
finished.


The aspect is triggered, but when I want to execute the initialize 
method, I got a linkage error.

All classes are public and the package is exported.

The aspect is as follows :
package org.eclipse.equinox.weaving.hello.aspects;
import org.aspectj.lang.annotation.AfterReturning;
import org.eclipse.equinox.weaving.demo.hello.internal.Initializable;

public aspect HelloAspect3 {   after() 
returning(Initializable initializable) : 
call(org.eclipse.equinox.weaving.demo.hello.internal.Initializable+.new(..)) 
{

   if( initializable != null) {
   System.out.println(After Initializable Constructor);
   initializable.initialize();
   } else {
   System.out.println(After Non-Initializable Constructor);
   }
   }
}

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] LinkageError when using after returning aspect in AspectJ for OSGI

[Martin Lippert]

Hi Dirk!

Do you have a small ready-to-use project that you can send me as zip? To 
me it looks like I should take a closer look into what happens here.


Thanks!
-Martin



Dirk Jacobs wrote:

I created an aspect bundle (a variation of the demo)

I want to have an initialize method called after a constructor has 
finished.


The aspect is triggered, but when I want to execute the initialize 
method, I got a linkage error.

All classes are public and the package is exported.

The aspect is as follows :
package org.eclipse.equinox.weaving.hello.aspects;
import org.aspectj.lang.annotation.AfterReturning;
import org.eclipse.equinox.weaving.demo.hello.internal.Initializable;

public aspect HelloAspect3 {   after() returning(Initializable 
initializable) : 
call(org.eclipse.equinox.weaving.demo.hello.internal.Initializable+.new(..)) 
{

   if( initializable != null) {
   System.out.println(After Initializable Constructor);
   initializable.initialize();
   } else {
   System.out.println(After Non-Initializable Constructor);
   }
   }
}

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [aspects] Pointcuts over types in separate bundle

[Martin Lippert]

Hi Yang!

I assume your target bundle defines an Import-Package on the common 
bundle as well as your aspect bundle. But how are the dependencies for 
your aspect bundle defined? There are two common cases:


- target bundle defines a Require-Bundle on the aspect bundle. Then your 
aspects get applied.


- your aspect bundle defines, for example, a Eclipse-SupplementBundle 
header in the manifest that points to your target bundle.


Which use case do you use?

-Martin




Meyer, Yang wrote:

Hi,

I am having problems defining pointcuts over an interface declared in a 
separate bundle:

I would like to weave an aspects bundle into a target bundle, using types in the 
common bundle for defining my pointcuts. The common bundle contains an interface that the 
target bundle uses and implements. Here's an example:

* The common bundle contains IServiceInterface, which declares two methods: 
void foo() and void bar().

* The target bundle has a class MyServiceImpl that implements the 
IServiceInterface. The target bundle also contains a class that uses the 
interface, something like this:
IServiceInterface myServiceImpl = new MyServiceImpl();
myServiceImpl.foo();

* The aspects bundle contains an aspect with the following advice:
before() : call(* IServiceInterface+.*(..)) {
// a service was invoked, do something else first
}

Obviously what I want is for the aspect to apply the advice to all invocations 
of all methods declared in IServiceInterface. However, the pointcut does not 
seem to match anything. (I first thought there was something wrong with my 
set-up/config, because the whole bundle wasn't woven, but it turned out that 
was just because none of the pointcuts matched.)

Is this sort of thing outright impossible, or am I just doing it wrong?

Thanks for your help,

Yang
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Move the equinox incubator to RT

[Martin Lippert]

Hi!

Just a question: If we don't move a particular project to the RT space, 
what happens to it? Can it still be accessed somewhere or will it be 
completely deleted?


The background of my question: We are currently discussing which 
projects of the aspects incubator area to more to RT. There are some 
projects that need some consolidation and the migration to RT might be a 
good chance to do so.


-Martin




Jeff McAffer wrote:
I agree that C is the way to go for all th reasons Tom mentioned plus:  The 
incubator is a distinct subproject with distinct commit rights etc.  spreading 
out the content will be confusing and just asking for things to graduate by 
accident


The incubator area should be structured according to the work areas which may or 
may not correspond to the formal components that we have in the rest of Equinox.


Jeff

Thomas Watson wrote:


I prefer something similar to option C. This is because we have examples of 
work areas that do not fit into any of the existing graduated categories. For 
example, the AspectJ stuff. I think it would be better to have one incubator 
folder with a different folder underneath for each workarea.


I am against option B. A flat structure has proven to be confusing and hard to 
find what you are looking for. I could be enticed to use option A if we allow 
new incubator work areas to have their own folder under org.eclipse.equinox. 
For example


org.eclipse.equinox/aspectj/incubator ...

Where org.eclipse.equinox/aspectj would not have any thing except the 
incubator folder because nothing has graduated from it yet. Once something 
graduates it would move up into the parent aspectj folder. A disadvantage to 
this approach is that it will pollute the org.eclipse.equinox/ folder with 
work areas that may never graduate and could be abandoned altogether.


Tom



Inactive hide details for Pascal Rapicault ---01/07/2009 09:51:57 AM---While 
this is being done, could we start talking about tPascal Rapicault 
---01/07/2009 09:51:57 AM---While this is being done, could we start talking 
about the shape of things in this incubator?



From:   
Pascal Rapicault pascal_rapica...@ca.ibm.com

To: 
Equinox development mailing list equinox-dev@eclipse.org

Cc: 
equinox-dev@eclipse.org, equinox-dev-boun...@eclipse.org

Date:   
01/07/2009 09:51 AM

Subject:
Re: [equinox-dev] Move the equinox incubator to RT





While this is being done, could we start talking about the shape of things in 
this incubator?

The current structure of the repo is:
org.eclipse.equinox/
framework/
bundles/
p2/
bundles/
[...]

What do we want:
A - one incubator folder under each work are in the repo?
org.eclipse.equinox/
framework/
bundles/
incubator/
p2/
bundles/
incubator/
[...]

B - one incubator and everything flat
org.eclipse.equinox/
incubator/
org.eclipse.equinox.p2.foo.bar
org.eclipse.log.zoo
framework/
bundles/
p2/
bundles/
[...]

C - one incubator with structure reflecting the work areas
org.eclipse.equinox/
incubator/
p2/
org.eclipse.equinox.p2.foo.bar
compendium/
org.eclipse.log.zoo
framework/
bundles/
p2/
bundles/
[...]

Personally I would vote for A.
What do you think?

PaScaL
Inactive hide details for Thomas Watson ---01/06/2009 05:24:45 PM---We have 
put this off long enough. As a New Year's resolutiThomas Watson ---01/06/2009 
05:24:45 PM---We have put this off long enough. As a New Year's resolution we 
will finally move the equinox incub


From:   
Thomas Watson tjwat...@us.ibm.com

To: 
equinox-dev@eclipse.org

Date:   
01/06/2009 05:24 PM

Subject:
[equinox-dev] Move the equinox incubator to RT





We have put this off long enough. As a New Year's resolution we will finally 
move the equinox incubator to its rightful place under RT-Equinox. We do not 
want to just move everything from the old equinox incubator over to the 
RT-Equinox because many projects in the old incubator are outdated and 
stagnant. We have opened a bug 
(_https://bugs.eclipse.org/bugs/show_bug.cgi?id=258483_) to determine what 
bundles from the equinox incubator are still active and should be moved over 
to the RT-Equinox repository.


At this time we are looking for folks on the Equinox team and the community to 
tell us what project from the incubator are still active. If you are using or 
maintaining a project in the equinox incubator then please chime into the bug 
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=258483_ and let us know what 
projects you would like to see migrated over. Once we have the list of 
projects determined then we will finalize the new repository layout for the 
equinox incubator. We want to have the list of projects finalized by M5 (end 
of January).


Tom
___
equinox-dev mailing list
equinox-...@eclipse.org_

Re: [equinox-dev] Equinox aspects: Several problems for Load-Time-Weaving in a eclipse product!

[Martin Lippert]

Hi Jens!


thanks for your message and hints!
I tried the new version and it works great.


Great to hear!!!

Cheers,
-Martin




Thanks,
Jens


Martin Lippert wrote:

Hi Jens!

I am sure we can get your setting to work well with equinox aspects. 
Firstofall, I see that you are using an old version of equinox aspects. 
You should definitely download and use M3 of equinox aspects, this is 
much more stable, especially in the case of dynamics.


Your config.ini looks good, I would just add a start level of 4 to the 
o.e.e.weaving.aspectj bundle. You definitely don't need to start your 
system with the osgi.clean option=true. The latest versions of equinox 
aspects work with and without cleaning the configuration area.


If you would like to use dynamics for aspects, the best way to go is to 
install and uninstall aspect bundles. Every time an aspect bundle is 
installed and got resolved, the aspect is woven into the system, 
including a refresh of already running bundles. Telling you that you 
need to know that some Eclipse bundles do not behave well within an 
dynamic environment. For example refreshing swt or the workbench at 
runtime does not work. So if you would like to dynamically install and 
uninstall aspects you should take care that the effected bundles behave 
nicely within a dynamic environment.


HTH,
-Martin


Jens Goldhammer wrote:

Hello,

I have downloaded the equinox aspectj extension and integrated into
eclipse
how it is mentioned in the user guide.
The hello world aspectj example works great for me. I can dynamically
start
and stop the aspectj service and the classes seam to be reloading at
run-time.

I have zipped the folders org.aspectj.runtime_1.6.1.2008070312 and
org.aspectj.weaver_1.6.1.2008070312 (project
org.eclipse.equinox.weaving.demo.target) from the example to two jar
files
and copied it to the eclipse plugins directory. I reloaded the target
platform, so the plugins are considered.  


After playing with some examples, I tried to integrate aspects into our
eclipse product which is based on 3.4.1. I have created a config.ini
(modified the prebaked config.ini of eclipse export mechanism) which
looks
like this one:

# default start level for the bundles
osgi.bundles.defaultStartLevel=4

[EMAIL PROTECTED]:start,
[EMAIL PROTECTED]:start, [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]:start, com.ibm.icu, [our bundles],
org.apache.log4j,org.aspectj.runtime,org.aspectj.weaver,org.eclipse.core.commands,org.eclipse.core.contenttype,org.eclipse.core.databinding,org.eclipse.core.expressions,org.eclipse.core.jobs,org.eclipse.core.runtime.compatibility.auth,org.eclipse.equinox.app,org.eclipse.equinox.event,org.eclipse.equinox.preferences,org.eclipse.equinox.registry,org.eclipse.equinox.weaving.aspectj,org.eclipse.equinox.weaving.caching,org.eclipse.equinox.weaving.caching.j9,org.eclipse.equinox.weaving.hook,org.eclipse.help,org.eclipse.jface,org.eclipse.jface.databinding,org.eclipse.osgi.services,org.eclipse.swt,org.eclipse.swt.win32.win32.x86,org.eclipse.ui,org.eclipse.ui.workbench,org.junit,org.eclipse.equinox.launcher,org.eclipse.equinox.launcher.win32.win32.x86

#osgi.configuration.cascaded=false
osgi.clean=true

# AOSGi
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.debug=true

After configuring it there are two problems:

1. If I start the product configuration via eclipse, I can see following
in
the osgi console after running ss:
4 LAZYorg.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
5 LAZYorg.eclipse.equinox.weaving.caching.j9_1.0.0.200808061839

The two bundles for aspectj are not active after starting the osgi
platform.
I don´t know why! Something prevents loading the aspectj bundles. My
presumption is that the required bundles
org.aspectj.runtime_1.6.1.2008070312.jar and
org.aspectj.weaver_1.6.1.2008070312.jar are loaded to late from the
org.eclipse.update.configurator which loads all bundles from the plugins
directory. Or anyboday think there is another problem?

After starting the two bundles manually with start [bundle-ids], my trace
aspect which traces method calls is working for this session. But how I
can
deactivate it during runtime? I made a stop for the bundle 4
(org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839) and the main
Activator of our application will be stopped!!! I thought I can
dynamically
start and stop the aspect bundle?

Another approach was to stop the bundle with the compiled aspect inside.
But
it does not work, too. The tracing still is working. I think, the aspect
is
cached... Can I prevent this?

2. I made a shutdown of the ogsi plattform and there are two different
situations.

2.1 If I restart the product WITHOUT the parameter osgi.clean=true, the
needed bundles are started:

4 ACTIVE  org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
5 ACTIVE

Re: [equinox-dev] Equinox aspects: Several problems for Load-Time-Weaving in a eclipse product!

[Martin Lippert]

Hi Jens!

I am sure we can get your setting to work well with equinox aspects. 
Firstofall, I see that you are using an old version of equinox aspects. 
You should definitely download and use M3 of equinox aspects, this is 
much more stable, especially in the case of dynamics.


Your config.ini looks good, I would just add a start level of 4 to the 
o.e.e.weaving.aspectj bundle. You definitely don't need to start your 
system with the osgi.clean option=true. The latest versions of equinox 
aspects work with and without cleaning the configuration area.


If you would like to use dynamics for aspects, the best way to go is to 
install and uninstall aspect bundles. Every time an aspect bundle is 
installed and got resolved, the aspect is woven into the system, 
including a refresh of already running bundles. Telling you that you 
need to know that some Eclipse bundles do not behave well within an 
dynamic environment. For example refreshing swt or the workbench at 
runtime does not work. So if you would like to dynamically install and 
uninstall aspects you should take care that the effected bundles behave 
nicely within a dynamic environment.


HTH,
-Martin


Jens Goldhammer wrote:

Hello,

I have downloaded the equinox aspectj extension and integrated into eclipse
how it is mentioned in the user guide.
The hello world aspectj example works great for me. I can dynamically start
and stop the aspectj service and the classes seam to be reloading at
run-time.

I have zipped the folders org.aspectj.runtime_1.6.1.2008070312 and
org.aspectj.weaver_1.6.1.2008070312 (project
org.eclipse.equinox.weaving.demo.target) from the example to two jar files
and copied it to the eclipse plugins directory. I reloaded the target
platform, so the plugins are considered.  


After playing with some examples, I tried to integrate aspects into our
eclipse product which is based on 3.4.1. I have created a config.ini
(modified the prebaked config.ini of eclipse export mechanism) which looks
like this one:

# default start level for the bundles
osgi.bundles.defaultStartLevel=4

[EMAIL PROTECTED]:start,
[EMAIL PROTECTED]:start, [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]:start, com.ibm.icu, [our bundles],
org.apache.log4j,org.aspectj.runtime,org.aspectj.weaver,org.eclipse.core.commands,org.eclipse.core.contenttype,org.eclipse.core.databinding,org.eclipse.core.expressions,org.eclipse.core.jobs,org.eclipse.core.runtime.compatibility.auth,org.eclipse.equinox.app,org.eclipse.equinox.event,org.eclipse.equinox.preferences,org.eclipse.equinox.registry,org.eclipse.equinox.weaving.aspectj,org.eclipse.equinox.weaving.caching,org.eclipse.equinox.weaving.caching.j9,org.eclipse.equinox.weaving.hook,org.eclipse.help,org.eclipse.jface,org.eclipse.jface.databinding,org.eclipse.osgi.services,org.eclipse.swt,org.eclipse.swt.win32.win32.x86,org.eclipse.ui,org.eclipse.ui.workbench,org.junit,org.eclipse.equinox.launcher,org.eclipse.equinox.launcher.win32.win32.x86

#osgi.configuration.cascaded=false
osgi.clean=true

# AOSGi
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.debug=true

After configuring it there are two problems:

1. If I start the product configuration via eclipse, I can see following in
the osgi console after running ss:
4 LAZYorg.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
5 LAZYorg.eclipse.equinox.weaving.caching.j9_1.0.0.200808061839

The two bundles for aspectj are not active after starting the osgi platform.
I don´t know why! Something prevents loading the aspectj bundles. My
presumption is that the required bundles
org.aspectj.runtime_1.6.1.2008070312.jar and
org.aspectj.weaver_1.6.1.2008070312.jar are loaded to late from the
org.eclipse.update.configurator which loads all bundles from the plugins
directory. Or anyboday think there is another problem?

After starting the two bundles manually with start [bundle-ids], my trace
aspect which traces method calls is working for this session. But how I can
deactivate it during runtime? I made a stop for the bundle 4
(org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839) and the main
Activator of our application will be stopped!!! I thought I can dynamically
start and stop the aspect bundle?

Another approach was to stop the bundle with the compiled aspect inside. But
it does not work, too. The tracing still is working. I think, the aspect is
cached... Can I prevent this?

2. I made a shutdown of the ogsi plattform and there are two different
situations.

2.1 If I restart the product WITHOUT the parameter osgi.clean=true, the
needed bundles are started:

4 ACTIVE  org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839
5 ACTIVE  org.eclipse.equinox.weaving.caching.j9_1.0.0.200808061839
6 ACTIVE  org.eclipse.equinox.weaving.caching_1.0.0.200808061839

My bundle with the aspect is also active. But I get severeal messages on
console 

Re: [equinox-dev] update site for equinox aspects

[Martin Lippert]

Hi!

Have equinox aspects be part of the incubator build would be great. I 
have a feature project in CVS, so who can help me make that part of the 
build and repo?


Thanks for your help!
-Martin




Jeff McAffer wrote:
I belive there is an incubator build.  You should be able to define some 
features, add them to that build and have the aspects stuff built all 
the time and put up on the Equinox build site and repo.


Jeff

Martin Lippert wrote:

Hi Andrew,

we don't have one yet, but I will try to figure out what is necessary 
to create one. Technically its not a problem but I am not sure where 
to put it. I will try to figure out.


Cheers,
-Martin


Andrew Eisenberg wrote:

Hi Martin and Heiko,

Do you have or are you planning on creating an update site for 
equinox aspects?

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] update site for equinox aspects

[Martin Lippert]

Hi Tom,

here we are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256347

Thanks for your help!
-Martin




Thomas Watson wrote:

Hi Martin,

I suggest opening a bug against Platform-Releng so that we can start
looking at doing this.  Please CC myself on the bug once you open it.


Tom




 
  From:   Martin Lippert [EMAIL PROTECTED]   
 
  To: Equinox development mailing list equinox-dev@eclipse.org 
 
  Date:   11/24/2008 03:30 PM
 
  Subject:Re: [equinox-dev] update site for equinox aspects  
 






Hi!

Have equinox aspects be part of the incubator build would be great. I
have a feature project in CVS, so who can help me make that part of the
build and repo?

Thanks for your help!
-Martin




Jeff McAffer wrote:

I belive there is an incubator build.  You should be able to define some
features, add them to that build and have the aspects stuff built all
the time and put up on the Equinox build site and repo.

Jeff

Martin Lippert wrote:

Hi Andrew,

we don't have one yet, but I will try to figure out what is necessary
to create one. Technically its not a problem but I am not sure where
to put it. I will try to figure out.

Cheers,
-Martin


Andrew Eisenberg wrote:

Hi Martin and Heiko,

Do you have or are you planning on creating an update site for
equinox aspects?
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev






___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] update site for equinox aspects

[Martin Lippert]

Hi Andrew,

we don't have one yet, but I will try to figure out what is necessary to 
create one. Technically its not a problem but I am not sure where to put 
it. I will try to figure out.


Cheers,
-Martin


Andrew Eisenberg wrote:

Hi Martin and Heiko,

Do you have or are you planning on creating an update site for equinox aspects?
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: how to turn off the 'bundle resolved' messages

[Martin Lippert]

Hi Oren!

I put a new dev build online, this should fix the problem.

HTH,
Martin


Martin Lippert wrote:

Hi Oren!

Looks like I committed some of my debug output statements to the
repository. I will remove them asap.

Sorry for that,
-Martin




Hi,



When working with Equinox Aspects on Eclipse 3.4.1 I get many messages of
the form:



bundle resolved: org.eclipse.equinox.common

bundle resolved: org.eclipse.equinox.weaving.caching

bundle resolved: org.eclipse.equinox.weaving.hook

bundle resolved: org.eclipse.update.configurator

bundle resolved: org.eclipse.core.runtime

bundle resolved: org.eclipse.equinox.weaving.aspectj

bundle resolved: org.tigris.subversion.clientadapter

bundle resolved: org.tigris.subversion.clientadapter.javahl

bundle resolved: org.tigris.subversion.clientadapter.javahl.win32

bundle resolved: org.sat4j.core

bundle resolved: org.sat4j.pb

bundle resolved: org.objectweb.asm

bundle resolved: org.objectweb.asm.source

bundle resolved: org.mortbay.jetty.source

bundle resolved: org.junit

.

.



Is it possible to turn them off?



Thanks,

Oren

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: how to turn off the 'bundle resolved' messages

[Martin Lippert]

Hi Oren!

Looks like I committed some of my debug output statements to the
repository. I will remove them asap.

Sorry for that,
-Martin



 Hi,



 When working with Equinox Aspects on Eclipse 3.4.1 I get many messages of
 the form:



 bundle resolved: org.eclipse.equinox.common

 bundle resolved: org.eclipse.equinox.weaving.caching

 bundle resolved: org.eclipse.equinox.weaving.hook

 bundle resolved: org.eclipse.update.configurator

 bundle resolved: org.eclipse.core.runtime

 bundle resolved: org.eclipse.equinox.weaving.aspectj

 bundle resolved: org.tigris.subversion.clientadapter

 bundle resolved: org.tigris.subversion.clientadapter.javahl

 bundle resolved: org.tigris.subversion.clientadapter.javahl.win32

 bundle resolved: org.sat4j.core

 bundle resolved: org.sat4j.pb

 bundle resolved: org.objectweb.asm

 bundle resolved: org.objectweb.asm.source

 bundle resolved: org.mortbay.jetty.source

 bundle resolved: org.junit

 .

 .



 Is it possible to turn them off?



 Thanks,

 Oren

 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] config.ini and equinox aspects

[Martin Lippert]

Hi Andrew!


Just tried out the latest version of equinox aspects and am
successfully weaving against OSGi head.  That's great.


:-)


However, I am still getting an error when the equinox aspects weaver
is started at level 1.  This problem goes away if I start it instead
at level 4.


Hm, that is strange. You are getting an error when the weaving service 
is started at level 1? What error do you get?



Starting the weaving service at level 4 doesn't seem to be giving me
any problems, but you are suggesting that it is not working.  Should I
not be doing this?


I am a bit irritating since starting with level 1 works for me, starting 
at level 4 not. Why do you have the opposite behavior? Interesting... ;-)


Would be nice to have a version that works with both... Working on that...

Can you nevertheless send me the error you get starting it at level 1?
Thanks!!!

-Martin




On Mon, Oct 27, 2008 at 2:01 PM, Martin Lippert [EMAIL PROTECTED] wrote:

Hi Andrew,

I committed some major changes inside the equinox aspects hook
implementation to fix some bugs. The problem with starting the weaving
service at a higher level is not yet fixed, but I would be happy to hear if
the current HEAD of equinox aspects works for you.

Thanks for your help!
-Martin




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] config.ini and equinox aspects

[Martin Lippert]

Hi Andrew,

this sounds quite reasonable. Can you try to set the start level of the 
simpleconfigurator to 1 and of the weaving service to 2 to see what happens?


-Martin


Andrew Eisenberg wrote:

As I mentioned earlier in this thread, I think it has something to do
with the simple configurator bundle
(org.eclipse.equinox.simpleconfigurator_1.0.0.v20080604.jar) and how
it is used to bootstrap the loading of other bundles.

Here is the exception I get (the first line of the stack trace only).
As I said, this exception is thrown, but somehow, the bundle is still
able to be loaded.

org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver;
bundle-version=0.0.0
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
snip/


What happens is this (I think):

1. there is an attempt to start the weaving service at level 1
2. but this requires starting org.aspectj.weaver and org.aspectj.runtime
3. since these two bundles are not specified in the config.ini, but
rather the org.eclipse.equinox.simpleconfigurator/bundles.info file,
these two bundles cannot be located until the simple configurator
bundle is completely started.  (so an exception is thrown)
4.  Once the simple configurator bundle is started, the aspectj weaver
and runtime can now be found and the weaving service can finally be
started.

(note- this is only a conjecture based on what I know about equinox (not much))

Does this make any sense?



On Mon, Oct 27, 2008 at 11:49 PM, Martin Lippert [EMAIL PROTECTED] wrote:

Hi Andrew!


Just tried out the latest version of equinox aspects and am
successfully weaving against OSGi head.  That's great.

:-)


However, I am still getting an error when the equinox aspects weaver
is started at level 1.  This problem goes away if I start it instead
at level 4.

Hm, that is strange. You are getting an error when the weaving service is
started at level 1? What error do you get?


Starting the weaving service at level 4 doesn't seem to be giving me
any problems, but you are suggesting that it is not working.  Should I
not be doing this?

I am a bit irritating since starting with level 1 works for me, starting at
level 4 not. Why do you have the opposite behavior? Interesting... ;-)

Would be nice to have a version that works with both... Working on that...

Can you nevertheless send me the error you get starting it at level 1?
Thanks!!!

-Martin





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: error can't determine modifiersof missing type

[Martin Lippert]

Hi Oren!


Indeed, re-exporting the pde.ui bundle solves the problem, thanks! Could you
please explain the meaning of the re-export statement and in particular when
should I re-export a dependent bundle? Should I simply re-export all
dependent bundles?


You don't need to re-export everything, definitely not. There are two 
different things that need a re-export:


- Types (aka packages) that the weaver injects into the target class 
that are not part of your aspect bundle.


- Types (aka packages) that the weaver needs for the weaving process 
itself (pointcut resolution, for example) that are not part of your 
aspect bundle.


Sometimes its get fuzzy to find out what to re-export and what not. 
Maybe we should open a bug for this to thing about making this easier to 
use. Would you open a bug in bugzilla for this? That would be great!


Thanks!!!

Best regards,
-Martin





Oren 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Lippert
Sent: Sunday, October 26, 2008 2:43 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Equinox Aspects: error can't determine
modifiersof missing type

Hi Oren!

The problem seems to occur when the jface bundle is woven and I assume 
that the weaver cannot resolve the type from the pde-ui bundle that you 
are using inside your aspect (the weaver needs to resolve that type if 
its directly used within the pointcut). What happens if you re-export 
the pde.ui bundle?


-Martin


Oren Mishali wrote:

Hi,

 


I'm trying to write a simple aspect that prints a message when the Cancel
button of a specific wizard (the Plug-in Project Creation Wizard) is
pressed. Here is the aspect's code:

 


import org.eclipse.pde.internal.ui.wizards.plugin.NewPluginProjectWizard;
//org.eclipse.pde.ui

import org.eclipse.jface.wizard.Wizard; // org.eclipse.jface

 


public aspect PluginWizardCancelPressed {

 


after(): execution(* Wizard.performCancel(..)) 
this(NewPluginProjectWizard){

System.out.println(thisJoinPoint);

}

}

 

 

 


Upon execution I get tons of errors (shown below), and the aspect has no
effect. Note that everything works fine when rewriting the aspect in the
following way:

 


public aspect PluginWizardCancelPressed {

 


after(Object obj): execution(* Wizard.performCancel(..)) 
this(obj){

if(obj instanceof  NewPluginProjectWizard)

System.out.println(thisJoinPoint);

}

}

 


Any suggestions?

 


Thanks,

Oren

 


The errors:

[org.eclipse.jface] error can't determine modifiers of missing type
org.eclipse.pde.internal.ui.wizards.plugin.NewPluginProjectWizard

when processing type mungers org.eclipse.jface.preference.IPreferenceStore

when processing type mungers 

when weaving 


 [Xlint:cantFindType]

[org.eclipse.jface] error can't determine modifiers of missing type
org.eclipse.pde.internal.ui.wizards.plugin.NewPluginProjectWizard

when processing type mungers org.eclipse.jface.internal.JFaceActivator

when processing type mungers 

when weaving 


 [Xlint:cantFindType]

[org.eclipse.jface] error can't determine modifiers of missing type
org.eclipse.pde.internal.ui.wizards.plugin.NewPluginProjectWizard

when processing type mungers org.eclipse.jface.dialogs.IDialogSettings

when processing type mungers 

when weaving 


 [Xlint:cantFindType]

[org.eclipse.jface] error can't determine modifiers of missing type
org.eclipse.pde.internal.ui.wizards.plugin.NewPluginProjectWizard

when processing type mungers

org.eclipse.jface.preference.PreferenceManager
when processing type mungers 


when weaving

.

.

 


The manifest of the plug-in project containing the aspect:

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: Repository Plug-in

Bundle-SymbolicName: org.highlevelaj.repository

Bundle-Version: 1.0.0

Bundle-Activator: org.highlevelaj.repository.Activator

Require-Bundle: org.eclipse.ui,

 org.eclipse.core.runtime,

 org.aspectj.runtime;visibility:=reexport,

 org.highlevelaj,

 org.eclipse.pde.ui

Eclipse-LazyStart: true

Export-Package: org.aspectj,

 org.highlevelaj.repository

Eclipse-SupplementBundle: org.eclipse.pde.ui, org.eclipse.jface

 

 

 

 







___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] config.ini and equinox aspects

[Martin Lippert]

Hi Andrew,


My question is, I would prefer to have the first option
([EMAIL PROTECTED]:start) are there any potential
problems with this?  Consider that I only want to weave a select few
bundles that all have a start level of 4.


We are still struggling a bit with the dynamics of the weaving service, 
but if I cannot figure that out until the next milestone (end of week), 
I will include an option to enable weaving service dynamics and disable 
it by default. Then you shouldn't have any problems starting the weaving 
service at level 4.


HTH,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspect for load-time weaving of AOP in OSGi

[Martin Lippert]

Hi Ying,

I am currently working on the next milestone build (M3) for equinox 
aspects (coming end of week) and I hope your setting works a lot better 
with that version. I will put a new dev build online soon and would be 
happy to hear your feedback from using that dev build. I will let you 
know when its available, ok?


-Martin


Ying Jiang wrote:

Dear Martin,

Thank you for the help. I tried to modify the config.ini according to
your suggestion. I also added osgi.clean=true:

osgi.framework.extensions=org.eclipse.equinox.weaving.hook
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true
[EMAIL PROTECTED]:start,
[EMAIL PROTECTED]:start,
[EMAIL PROTECTED],
[EMAIL PROTECTED]:start,
org.eclipse.equinox.weaving.caching@:start
osgi.clean=true

But the hello view was supplemented twice during startup:

[org.aspectj.osgi] info adding AspectJ hooks ...

osgi [org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info Starting AspectJ weaving service ...
[org.aspectj.osgi] info triggering update for re-supplementing myview
[org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.core.runtime'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.equinox.registry'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.core.runtime.compatibility.auth'
...
...
-
It's supplemented before and after Starting AspectJ weaving service
respectively. And the status of hello view
(org.eclipse.equinox.weaving.demo.hello) is INSTALLED instead of
RESOLVED. hello view is not available in the view list.

Could you please tell me why it happened and how to resolve this problem?

Regards,

Ying Jiang

On Fri, Oct 24, 2008 at 2:49 AM, Martin Lippert [EMAIL PROTECTED] wrote:

Hi Ying,

to ensure that the weaving service starts before anything else you should
add the weaving service bundle to the config.ini of your launch
configuration and set the start level to 1. So your osgi.bundles entry in
your config.ini might look like:

[EMAIL PROTECTED]:start,[EMAIL PROTECTED]:start,[EMAIL PROTECTED],
[EMAIL PROTECTED]:start,
org.eclipse.equinox.weaving.caching@:start, your.aspect.bundle.symbolic.name

You could even put your aspect bundle onto that list to ensure that no
dynamic struggle happens.

And I think you don't need to depend on the aspectj bundle from your aspect
bundle. Should work without that dependency.

HTH,
-Martin




Ying Jiang wrote:

Dear Sir,

I would like to use Equinox Aspect for load-time weaving of AOP in
OSGi. I'm now trying the Quick-start guide from

http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php;.

I make a few changes of the demo:

1. I change the bundle of org.eclipse.equinox.weaving.demo.hello
into a Plug-in with a View(org.eclipse.ui.part.ViewPart). Another
bundle of org.eclipse.equinox.weaving.demo.hello.aspects contains
the aspect of printing a string before the view is showed in the
workbench. The two bundles are two Eclipse plugin projects in my
workspace.

2. I copy the other required bundles (org.aspectj.runtime,
org.aspectj.weaver, org.eclipse.equinox.weaving.aspectj,
org.eclipse.equinox.weaving.hook... and so on) to the plugins
directory of eclipse.

3. I launch a new workbench by using Eclipse Application
configuration instead of command line.

Finally, I get the following outputs:
[org.aspectj.osgi] info adding AspectJ hooks ...

osgi [org.aspectj.osgi] info triggering update for re-supplementing
org.eclipse.equinox.weaving.demo.hello
[org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info Starting AspectJ weaving service
...
[org.aspectj.osgi] info triggering update for re-supplementing
org.eclipse.equinox.weaving.demo.hello
[org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.ide.application'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.workbench'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.jface'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.swt'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui'
...
...
...

And I can not find the new hello view in the Show View dialog.

Could you please tell me why org.eclipse.equinox.weaving.demo.hello
is re-supplemented twice but fails to become resolved?

Here is the Manifest information of
org.eclipse.equinox.weaving.demo.hello.aspects:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Equinox Aspects Demo - Hello aspects

Re: [equinox-dev] Equinox Aspect for load-time weaving of AOP in OSGi

[Martin Lippert]

Hi Ying,

to ensure that the weaving service starts before anything else you 
should add the weaving service bundle to the config.ini of your launch 
configuration and set the start level to 1. So your osgi.bundles entry 
in your config.ini might look like:


[EMAIL PROTECTED]:start,[EMAIL PROTECTED]:start,[EMAIL PROTECTED], 
[EMAIL PROTECTED]:start, 
org.eclipse.equinox.weaving.caching@:start, your.aspect.bundle.symbolic.name


You could even put your aspect bundle onto that list to ensure that no 
dynamic struggle happens.


And I think you don't need to depend on the aspectj bundle from your 
aspect bundle. Should work without that dependency.


HTH,
-Martin




Ying Jiang wrote:

Dear Sir,

I would like to use Equinox Aspect for load-time weaving of AOP in
OSGi. I'm now trying the Quick-start guide from
http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php;.

I make a few changes of the demo:

1. I change the bundle of org.eclipse.equinox.weaving.demo.hello
into a Plug-in with a View(org.eclipse.ui.part.ViewPart). Another
bundle of org.eclipse.equinox.weaving.demo.hello.aspects contains
the aspect of printing a string before the view is showed in the
workbench. The two bundles are two Eclipse plugin projects in my
workspace.

2. I copy the other required bundles (org.aspectj.runtime,
org.aspectj.weaver, org.eclipse.equinox.weaving.aspectj,
org.eclipse.equinox.weaving.hook... and so on) to the plugins
directory of eclipse.

3. I launch a new workbench by using Eclipse Application
configuration instead of command line.

Finally, I get the following outputs:
[org.aspectj.osgi] info adding AspectJ hooks ...

osgi [org.aspectj.osgi] info triggering update for re-supplementing
org.eclipse.equinox.weaving.demo.hello
[org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info Starting AspectJ weaving service ...
[org.aspectj.osgi] info triggering update for re-supplementing
org.eclipse.equinox.weaving.demo.hello
[org.aspectj.osgi] info supplementing
org.eclipse.equinox.weaving.demo.hello with
[org.eclipse.equinox.weaving.demo.hello.aspects]
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.ide.application'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.workbench'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.jface'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.swt'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.ui'
...
...
...

And I can not find the new hello view in the Show View dialog.

Could you please tell me why org.eclipse.equinox.weaving.demo.hello
is re-supplemented twice but fails to become resolved?

Here is the Manifest information of
org.eclipse.equinox.weaving.demo.hello.aspects:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Equinox Aspects Demo - Hello aspects
Bundle-SymbolicName: org.eclipse.equinox.weaving.demo.hello.aspects
Bundle-Version: 1.0.0
Bundle-Vendor: Heiko Seeberger
Require-Bundle: org.aspectj.runtime;bundle-version=1.6.1;visibility:=reexport,
 org.eclipse.equinox.weaving.aspectj
Export-Package: org.eclipse.equinox.weaving.demo.hello.aspects
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Import-Package: org.osgi.framework;version=1.4.0
Eclipse-SupplementBundle: org.eclipse.equinox.weaving.demo.hello

If I remove the Require-Bundle of
org.eclipse.equinox.weaving.aspectj from the Manifest, sometimes I
get the same outputs above, but sometimes the outputs change into:
[org.aspectj.osgi] info adding AspectJ hooks ...

osgi [org.aspectj.osgi.service.weaving] info Starting AspectJ weaving
service ...
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.ide.application'
[org.aspectj.osgi.service.weaving] info not weaving bundle
'org.eclipse.ui.workbench'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.jface'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.swt'
[org.aspectj.osgi.service.weaving] info not weaving bundle 'org.eclipse.ui'
...
...
...
It shows there's no weaving at all, even for
org.eclipse.equinox.weaving.demo.hello. But in this circumstatnce,
the hello view shows well without the aspect's effect.

I wonder if the problems come from The AspectJ weaving service
(bundle org.eclipse.equinox.weaving.aspectj) has to be started before
any classes are loaded from any bundles targeted for weaving.. I
don't know how to make sure the the AspectJ weaving service to be
started at first.

Could you tell me the reasons for the problems and the corresponding
solutions please?
It's urgent. Thank you in advance!

Ying Jiang
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list

Re: [equinox-dev] Problems starting Equinox Aspects on the command line

[Martin Lippert]

Hi Thorsten!

I think I have solved your issue. If you start equinox aspects from the 
command line you need to add the o.e.e.weaving.hook bundle jar to the 
classpath of the JVM when starting osgi. Otherwise the equinox aspects 
framework extension cannot be configured during startup.


There is another thing you need to take care of: set the system property 
osgi.compatibility.bootdelegation=true to let the weaving service find 
the xml parsers from the JDK. Equinox operates at a more strict mode 
when started from command line.


My config.ini file looks like this:

osgi.bundles=org.aspectj.runtime, org.aspectj.weaver, 
[EMAIL PROTECTED]:start, 
org.eclipse.equinox.weaving.demo.hello.aspects, 
org.eclipse.equinox.weaving.demo.hello

osgi.bundles.defaultStartLevel=5
osgi.framework=org.eclipse.osgi
osgi.configuration.cascaded=false

# Equinox Aspects
osgi.framework.extensions=org.eclipse.equinox.weaving.hook
org.aspectj.osgi.verbose=true


My command line looks like this:

java -Dosgi.compatibility.bootdelegation=true -cp 
org.eclipse.osgi_3.4.0.v20080605-1900.jar;org.eclipse.equinox.weaving.hook_1.0.0.200808202116.jar 
 org.eclipse.core.runtime.adaptor.EclipseStarter -console



HTH,
-Martin




Thorsten Harbig wrote:

Hello Mr Lippert,

would it be possible to get a ready to go example of aspects equinox for
the command line? Similar to the one from the EquinoxAspects page for
Eclipse?

Becuase I was not able to start it from the command line. I thought it
shouldn't be any difference whether we start it from within eclipse or
just standalone.

Actually I downloaded already the target runtime, so I would only need an
adjusted config.ini plus the command line instructions to start the osgi
bundles.

bye
thorsten


Hi Thorsten!

What happens if you start the aspectj weaving service bundle directly at
start level 1 from the config.ini? Does it make any difference or do you
get the same ClassNotFoundException?

-Martin




[EMAIL PROTECTED] wrote:

Looking at this I have got one question: Are the system bundle
(org.eclipse.osgi) and the framework extension fragment
(org.eclipse.equinox.weaving.hook) colocated, i.e. in the same
directory? That is neccessary for Equinox to recognize the framework
extension (see http://wiki.eclipse.org/index.php/Adaptor_Hooks for
details) = Equinox Aspects will not work if the both bundles are not
colocated.

Yes, I have all bundles within the same directory.

- org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar (file)
- org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar (file)
- org.eclipse.osgi_3.4.0.v20080605-1900.jar (file)
- org.aspectj.weaver_1.6.1.2008070312 (dir)
- org.aspectj.runtime_1.6.1.2008070312 (dir)
(like it is delivered with the equinox-aspects-demo-hello.zip)

Additionally I copied the two exported bundles
- org.eclipse.equinox.weaving.demo.hello.aspects
- org.eclipse.equinox.weaving.demo.hello
into the same directory.

Than I created a configuration directory where I added the config.ini
with
the necessary bundles and the hook information
osgi.framework.extensions=org.eclipse.equinox.weaving.hook

now I start it from the command line in the directory where all the
bundles are located.


Actually the org.eclipse.equinox.weaving.demo.hello just works fine for
me, but without the augmentation through the aspect of course.

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev








___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Problems starting Equinox Aspects on the command line

[Martin Lippert]

Hi Thorsten!

What happens if you start the aspectj weaving service bundle directly at 
start level 1 from the config.ini? Does it make any difference or do you 
get the same ClassNotFoundException?


-Martin




[EMAIL PROTECTED] wrote:

Looking at this I have got one question: Are the system bundle
(org.eclipse.osgi) and the framework extension fragment
(org.eclipse.equinox.weaving.hook) colocated, i.e. in the same
directory? That is neccessary for Equinox to recognize the framework
extension (see http://wiki.eclipse.org/index.php/Adaptor_Hooks for
details) = Equinox Aspects will not work if the both bundles are not
colocated.


Yes, I have all bundles within the same directory.

- org.eclipse.equinox.weaving.aspectj_1.0.0.200808061839.jar (file)
- org.eclipse.equinox.weaving.hook_1.0.0.200808061839.jar (file)
- org.eclipse.osgi_3.4.0.v20080605-1900.jar (file)
- org.aspectj.weaver_1.6.1.2008070312 (dir)
- org.aspectj.runtime_1.6.1.2008070312 (dir)
(like it is delivered with the equinox-aspects-demo-hello.zip)

Additionally I copied the two exported bundles
- org.eclipse.equinox.weaving.demo.hello.aspects
- org.eclipse.equinox.weaving.demo.hello
into the same directory.

Than I created a configuration directory where I added the config.ini with
the necessary bundles and the hook information
osgi.framework.extensions=org.eclipse.equinox.weaving.hook

now I start it from the command line in the directory where all the
bundles are located.


Actually the org.eclipse.equinox.weaving.demo.hello just works fine for
me, but without the augmentation through the aspect of course.

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: AW: [equinox-dev] Problems with Equinoxs Aspects

[Martin Lippert]

Hi Sebastian!


Thanks for your help but that isn't the problem.
org.aspectj.runtime and org.aspectj.weaver are installed in my target
environment and Eclipse-SupplementBundle is specifying my bundle
org.ssoft.test directly.

I attach the plug-ins.


Thanks for the zip, that made it a lot easier for find the problem. You 
are just missing org.eclipse.update.configurator in the set of 
selected plugins. Select this and your RCP app will appear... :-)


HTH,
-Martin





Sebastian

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Martin Lippert
Gesendet: Montag, 21. Juli 2008 13:38
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Problems with Equinoxs Aspects

Hi Sebastian!

Seems like your configuration is missing something. Do you have 
org.aspectj.runtime and org.aspectj.weaver installed in your target 
environment?


Btw: Did you define the Eclipse-SupplementBundle just for your 
org.ssoft.test bundle or did you wrote *? Specifying your bundle 
directly would be the better option.


-Martin



Sebastian Staack wrote:

Hi everbody

I have a problem with a RCP application and equinox aspects. I hope

somebody

can help me.

Ok my Application consists of two plugins: org.ssoft.test and
org.ssoft.test.aspects.

org.ssoft.test is the hello world rcp example and

org.ssoft.test.aspects contains an aspect. This aspect affects all method
calls in the Application class of org.ssoft.test.

it also contains the aop.xml file and it declares eclipse-supplementbundle
in the manifest file and it reexports the the dependencie from
org.aspectj.runtime.

My problem is the config.ini to start the application. Can somebody give

me

a hint how the config.ini should look like.

Here is my attempt but it doesn't work:



[EMAIL PROTECTED]:start,org.eclipse.update.configur

[EMAIL PROTECTED]:start,[EMAIL PROTECTED],
org.eclipse.equinox.weaving.aspectj@:start,
org.eclipse.equinox.weaving.caching@:start, org.ssoft.test,
org.ssoft.test.aspect

osgi.bundles.defaultStartLevel=4

osgi.framework=org.eclipse.osgi

osgi.configuration.cascaded=false

 

 


# AOSGi

osgi.framework.extensions=org.eclipse.equinox.weaving.hook

org.aspectj.weaver.loadtime.configuration=org/aspectj/aop.xml

#aj.weaving.verbose=true

org.aspectj.weaver.showWeaveInfo=true

#org.aspectj.osgi.verbose=true

 


I get following error log:

!SESSION 2008-07-21 13:00:03.791
---

eclipse.buildId=unknown

java.version=1.6.0_02

java.vendor=Sun Microsystems Inc.

BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE

Framework arguments:  -application org.ssoft.test.application

Command-line arguments:  -application org.ssoft.test.application -data
C:\Dokumente und Einstellungen\Sebastian
Staack\workspace/../runtime-org.ssoft.test.application -dev
file:C:/Dokumente und Einstellungen/Sebastian


Staack/workspace/.metadata/.plugins/org.eclipse.pde.core/org.ssoft.test.appl

ication/dev.properties -os win32 -ws win32 -arch x86 -console

 


!ENTRY org.eclipse.core.runtime 4 0 2008-07-21 13:00:05.003

!MESSAGE 


!STACK 0

org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Require-Bundle: org.eclipse.core.jobs;
bundle-version=[3.2.0,4.0.0)

  at


org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.j

ava:305)

  at


org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundl

e.java:355)

  at


org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.ja

va:1074)

  at


org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(Sta

rtLevelManager.java:616)

  at


org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLeve

lManager.java:508)

  at


org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(S

tartLevelManager.java:299)

  at


org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(Sta

rtLevelManager.java:489)

  at


org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.

java:211)

  at


org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManage

r.java:321)

 


!ENTRY org.eclipse.equinox.weaving.aspectj 4 0 2008-07-21 13:00:05.013

!MESSAGE 


!STACK 0

org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver;
bundle-version=0.0.0

  at


org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.j

ava:305)

  at


org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundl

e.java:355)

  at


org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.ja

va:1074)

  at


org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(Sta

rtLevelManager.java:616

Re: [equinox-dev] News from Equinox Aspects

[Martin Lippert]

Hi Andrew!


That's great news!  Congratulations.


Thanks!


We are considering using Equinox Aspects with AJDT and so this could
possibly be a big help for us.

The reason why we are looking into Equinox Aspects is that for a long
time we had hoped that the JDT team would open up some of its inner
functionality to us via extension points, but so far they have not.
So, we now think that the best approach is to weave into the JDT in a
very precise way so that we can extend JDT in an exact manner.

I'm sure I will be asking for some help soon.


You are very welcome! We would be very very happy to help you with this.

Aside of that we would like to investigate at some point in the near 
future what would be necessary have more support within AJDT for the 
load-time weaving setting. Maybe we can discuss this sometime?


Thanks!

-Martin





thanks,
--a

On Mon, Jul 14, 2008 at 9:26 PM, Heiko Seeberger
[EMAIL PROTECTED] wrote:

Hi,
Equinox Aspects (some time ago also called AOSGi) has been around for quite
a while now. There has been a lot of community feedback and we have even
seen Equinox Aspects performing in real-world projects. Therefore the
Equinox Aspects team thinks that it is time to move one big step forward: We
aim at graduating from incubator.

One first task to achieve this goal was to align with common Eclipse/Equinox
release and naming conventions:

In the past we created some packages called releases without proper reviews
and also used version numbers = 1. We currently took all these back. In the
future we will create development and milestone builds on our way to a
formal 1.0 release. Our current build is 200807082136 development, the
first milestone build is scheduled for August 8th. Please ignore all former
versions.

We also renamed the bundles to better fit into the Eclipse/Equinox world:
org.aspectj.osgi - org.eclipse.equinox.weaving.hook
org.aspectj.osgi.service.weaving - org.eclipse.equinox.weaving.aspectj
org.aspectj.osgi.service.caching - org.eclipse.equinox.weaving.caching
org.aspectj.osgi.service.caching.j9 -
org.eclipse.equinox.weaving.caching.j9

Please ignore the old bundles from now on. Migrating your system from the
old bundles to the new one should be pretty easy. Just ensure that your
configuration refers now to the new bundles instead of the old ones, thats
it.

If you are interested in our release plan, already added featurs and fixed
bugs, please take a look at our Wiki page:

http://wiki.eclipse.org/Equinox_Aspects_Plan

We are looking forward to your feedback and ideas.

Regards
Martin and Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] how to install framework extensions

[Martin Lippert]

Hi all!

I have a question with regards to framework extensions. Currently people 
who are using equinox aspects for example have to define


-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

to enable the equinox aspects framework extension. Is there an easier 
way for people who are installing the framework extension via an update 
site or p2? I don't would like to tell them to edit config.ini or 
something like that...


Thanks for your help!
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] how to install framework extensions

[Martin Lippert]

Hi John,

Hi Martin, this is indeed possible with p2.  The p2 metadata of your 
bundle can specify an instruction to add that property when your bundle is 
installed. There is a bug report with a discussion about this and the 
solution is described there:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=231557#c8


That sounds quite good. Thanks for this!!!

I added this to the discussion of this one:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=240047

Thanks again,
-Martin




John





Martin Lippert [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]

07/09/2008 08:28 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
Equinox Project equinox-dev@eclipse.org
cc

Subject
[equinox-dev] how to install framework extensions






Hi all!

I have a question with regards to framework extensions. Currently people 
who are using equinox aspects for example have to define


-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

to enable the equinox aspects framework extension. Is there an easier 
way for people who are installing the framework extension via an update 
site or p2? I don't would like to tell them to edit config.ini or 
something like that...


Thanks for your help!
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev






___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Aspects: problem weaving same class file in different bundles

[Martin Lippert]

Hi Stuart,


another possibility would be to import and export the 'widgets'
package from both widget bundles, then they would both see
the same class regardless of the order they were installed.

eg:

  Export-Package: widgets
  Import-Package: org.osgi.framework, widgets

see:
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html


Good idea, haven't thought about this one. But that means also that both 
widget bundles see the same class (so one of the two Widget classes). If 
they are different from each other (for some reason, don't know), this 
won't work, right?


-Martin




Just a first idea, there might be other solutions for your problem. Tell me

more about why you choose this design and we could discuss alternatives, ok?

HTH,
-Martin






sorbus wrote:


Martin wrote:


Hi Rowan,

I assume the problem is that the aspect should weave the same class from

different bundles. For the aspect both Widget classes are visible (because

both should be woven) and the weaver does not know which one to use for
type resolution. But this is just a first guess on the problem... Would you
submit a bug in bugzilla for this issue?

Different aspects in different bundles with more specific supplement
definitions should workaround this problem, but I really would like to
investigate this problem in more detail (therefore the bug). Would be great
if you could create a small test case for this to reproduce.


I think the test case is a good idea (see below). I would rather you
take a look at that first before I submit a bug because I am at the
stage of learning BOTH equinox-aspects AND aspectj so possibly missed
something simple :-)

Description of problem (using a simple test case)

I have a very simple bundle (Widget) which has an Activator class and
a Widget class.

The Activator start() method prints out the Bundle Symbolic Name, then
instantiates a Widget

The Widget class looks like this:
package widgets;

public class Widget {
  private String wUID;
  public Widget() {
  init();
  }

  private void init() {
 wUID = java.util.UUID.randomUUID().toString();
 System.out.println(Widget has been assigned UID:  + wUID);
  }

  public void doSomething() {
 System.out.println(Widget  + wUID +  has done something);
  }
}

So the constructor calls the init() method which creates a random
UUID, assigns it, and prints it out.

I have two such bundles with a slightly different manifest file
(different Bundle Symbolic Name):

widgetbundle1.jar - Bundle Symbolic Name: Widget_01234
widgetbundle2.jar - Bundle Symbolic Name: Widget_56789

Example manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Bundle
Bundle-SymbolicName: Widget_01234
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Bundle-Activator: widgets.Activator
Import-Package: org.osgi.framework
Export-Package: widgets
Bundle-Description: Testing Aspects in OSGi...

The aspects look like this:
package widgetaspects;

import widgets.*;

public aspect MyAspects {
  pointcut doInit(Widget w):
 execution(void Widget.init(..))  target(w);

  after(Widget w) : doInit(w)  {
 System.out.println(In the AFTER advice for doInit());
 System.out.println(target: + thisJoinPoint.getTarget());
 System.out.println(this: + thisJoinPoint.getThis());
 w.doSomething();
  }
}

A pointcut is defined on the execution of the Widget init() method. In
the after advice, the Widget doSomething() method is called.

My aop.xml file looks like this:
?xml version=1.0?
aspectj
   aspects
   aspect name=widgetaspects.MyAspects/
   /aspects
/aspectj

and is installed in org/aspectj/aop.xml in the widget-aspects jar file.

Aspect bundle manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Aspects
Bundle-SymbolicName: widgetaspects
Bundle-Version: 1.0.0
Export-Package: widgetaspects,org.aspectj
Import-Package: widgets
Require-Bundle: org.aspectj.runtime;visibility:=reexport
Eclipse-SupplementBundle: Widget_*
Bundle-ClassPath: .

If I install EITHER widgetbundle1 OR widgetbundle2 and the
widget-aspects bundle, then start the widgetbundle then it works and I
get this on the console:

Starting Widget Bundle: Widget_01234
[Widget_01234] weaveinfo Join point 'method-execution(void
widgets.Widget.init())' in Type 'widgets.Widget' (Widget.java:12)
advised by after advice from 'widgetaspects.MyAspects'
(MyAspects.aj:10) [with runtime test]
Widget has been assigned UID: 5356811b-3475-448e-8f9b-83a85fa98d3e
In the AFTER advice for doInit()
target:[EMAIL PROTECTED]
this:[EMAIL PROTECTED]
Widget 5356811b-3475-448e-8f9b-83a85fa98d3e has done something

If I install BOTH widgetbundles and the widget-aspects bundle, then
start one widgetbundle, that works as before. Starting the second
widgetbundle I get this on the console:

Starting Widget Bundle: Widget_56789
[Widget_56789] weaveinfo Join point 'method-execution(void
widgets.Widget.init())' in Type 'widgets.Widget' (Widget.java:12)
advised by after 

Re: [equinox-dev] Aspects: problem weaving same class file in different bundles

[Martin Lippert]

Hi Rowan,

I looked at your example and I think I have found the problem. Your 
aspect bundle imports the package widgets and can therefore refer to 
your class Widget. But since both widget bundles export the same package 
including the same class (Widget), the aspect definition is wired to 
only one of them. Therefore the code of the aspect refers to one of 
those Widget class definitions (this is standard Java and OSGi behavior).


Now you try to weave both widget bundles. The weaver for widget bundle 1 
can weave your class successfully since this weaver sees the same class 
for Widget as your aspect bundle. The weaver for widget bundle 2 sees 
its own widget class but the aspect bundle is wired to the other one. 
Therefore the linkage error happens.


This seems not like a bug in Equinox Aspects nor the AspectJ weaver. 
Having the same class (with the same package) within different bundles 
seems not to be a nice design anyway. Do you have a specific reason for 
that? You could solve your problem by extracting an abstract superclass 
for your Widget classes, putting this superclass in a separate bundle 
and let the aspect weave against this superclass while having subclasses 
in your other bundles.


Just a first idea, there might be other solutions for your problem. Tell 
me more about why you choose this design and we could discuss 
alternatives, ok?


HTH,
-Martin





sorbus wrote:

Martin wrote:

Hi Rowan,

I assume the problem is that the aspect should weave the same class from different 
bundles. For the aspect both Widget classes are visible (because both should be woven) 
and the weaver does not know which one to use for type resolution. But this is just a 
first guess on the problem... Would you submit a bug in bugzilla for this issue?

Different aspects in different bundles with more specific supplement definitions 
should workaround this problem, but I really would like to investigate this problem 
in more detail (therefore the bug). Would be great if you could create a small test 
case for this to reproduce.


I think the test case is a good idea (see below). I would rather you
take a look at that first before I submit a bug because I am at the
stage of learning BOTH equinox-aspects AND aspectj so possibly missed
something simple :-)

Description of problem (using a simple test case)

I have a very simple bundle (Widget) which has an Activator class and
a Widget class.

The Activator start() method prints out the Bundle Symbolic Name, then
instantiates a Widget

The Widget class looks like this:
package widgets;

public class Widget {
   private String wUID;
   public Widget() {
   init();
   }

   private void init() {
  wUID = java.util.UUID.randomUUID().toString();
  System.out.println(Widget has been assigned UID:  + wUID);
   }

   public void doSomething() {
  System.out.println(Widget  + wUID +  has done something);
   }
}

So the constructor calls the init() method which creates a random
UUID, assigns it, and prints it out.

I have two such bundles with a slightly different manifest file
(different Bundle Symbolic Name):

widgetbundle1.jar - Bundle Symbolic Name: Widget_01234
widgetbundle2.jar - Bundle Symbolic Name: Widget_56789

Example manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Bundle
Bundle-SymbolicName: Widget_01234
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Bundle-Activator: widgets.Activator
Import-Package: org.osgi.framework
Export-Package: widgets
Bundle-Description: Testing Aspects in OSGi...

The aspects look like this:
package widgetaspects;

import widgets.*;

public aspect MyAspects {
   pointcut doInit(Widget w):
  execution(void Widget.init(..))  target(w);

   after(Widget w) : doInit(w)  {
  System.out.println(In the AFTER advice for doInit());
  System.out.println(target: + thisJoinPoint.getTarget());
  System.out.println(this: + thisJoinPoint.getThis());
  w.doSomething();
   }
}

A pointcut is defined on the execution of the Widget init() method. In
the after advice, the Widget doSomething() method is called.

My aop.xml file looks like this:
?xml version=1.0?
aspectj
aspects
aspect name=widgetaspects.MyAspects/
/aspects
/aspectj

and is installed in org/aspectj/aop.xml in the widget-aspects jar file.

Aspect bundle manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Aspects
Bundle-SymbolicName: widgetaspects
Bundle-Version: 1.0.0
Export-Package: widgetaspects,org.aspectj
Import-Package: widgets
Require-Bundle: org.aspectj.runtime;visibility:=reexport
Eclipse-SupplementBundle: Widget_*
Bundle-ClassPath: .

If I install EITHER widgetbundle1 OR widgetbundle2 and the
widget-aspects bundle, then start the widgetbundle then it works and I
get this on the console:

Starting Widget Bundle: Widget_01234
[Widget_01234] weaveinfo Join point 'method-execution(void
widgets.Widget.init())' in Type 'widgets.Widget' (Widget.java:12)
advised by after 

Re: [equinox-dev] Aspects: problem weaving same class file in different bundles

[Martin Lippert]

Hi Rowan,

I assume the problem is that the aspect should weave the same class from 
different bundles. For the aspect both Widget classes are visible 
(because both should be woven) and the weaver does not know which one to 
use for type resolution. But this is just a first guess on the 
problem... Would you submit a bug in bugzilla for this issue?


Different aspects in different bundles with more specific supplement 
definitions should workaround this problem, but I really would like to 
investigate this problem in more detail (therefore the bug). Would be 
great if you could create a small test case for this to reproduce.


-Martin



sorbus wrote:

I suspect I can't do what I want to, but here goes anyway

I have two 'applications' as bundles in equinox. Each use the same
code, they only differ in configuration and Bundle-SymbolicName. By
same code I mean they have identical copies, not shared code/services
or anything. Like this:

Bundle A
Bundle-SymbolicName: Widget_1
Has class Widget

Bundle B
Bundle-SymbolicName: Widget_2
Has class Widget

I have a separate bundle for the aspects which has this in the header:
Eclipse-SupplementBundle: Widget_*

If I install all three bundles and start bundle A then all fine. If I
then start B I get errors such as:
java.lang.LinkageError: loader constraint violation.
.MyAspects have different Class objects for the type Widget used
in the signature

I can understand what is happening I think, the Widget object having
already been woven, can not be woven again.

Is there a way around this? Would it help (possible?) to have a more
tightly defined pointcut (currently using constructor call on Widget),
ie something which can distinguish between the two Widgets?

Would it help to have aspects for each Widget in separate bundles and
have a more specific Eclipse-SupplementBundle header?

Rowan
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

[Martin Lippert]

Hi Jeff,


This sounds like a good plan.  Thanks for being proactive on this.
It will be interesting to see what happens with the *new* lower 
version.  For exapmle, if the update sites that people use have both the 
new and old with the new version being lower then users likely will not 
be able to get the right thing.  Would you see removing the older versions?


I think we should create a new update site for this.

As for the graduation review, do you have a set of code that you would 
like to release now?  If that is true then you might just graduate with 
a higher version number and remove the old versions.


I think that either option would be fine.  Thanks again.


Our current idea is to start with the lower version number, then build a 
number of milestone builds over the next months and graduate after this 
period (maybe by the end of this or beginning of next year). Does this 
sound reasonable?


-Martin





Jeff

Martin Lippert wrote:

Hi Jeff,

we discussed this briefly and the result is: we would like to do ALL 
this stuff... ;-)


Our idea would be:

1. lower the version numbers to make the incubator status clear. This 
includes communication with the community to avoid confusion and to 
make clear that this does not include lowering the quality of the code 
produced so far... ;-)


2. produce some more milestone builds instead of what we called 
releases in the past. We will write up a project plan as a wiki page 
that includes open bugs and our goals for upcoming milestone builds.


3. start the graduation process for a future first release of equinox 
aspects including reviews, a release review and whatever is necessary 
to graduate... :-)


What do you think?

-Martin



Jeff McAffer wrote:

Possible solutions:
- graduate
- lower the version numbers

In either case there will need to be a review if there is going to be 
a release.  You could avoid a review if the version number is 
lowered AND the event is rephrased as a milestone.


As for dealing with the past, well, dropping the version numbers 
would certainly cause some confusion.  Graduation would retain the 
version number sequence but we'd have to have a discussion in the 
wider community to see if graduation is warranted (I have no evidence 
either way at this point).


I'm certainly open to alternatives.

Jeff
Martin Lippert wrote:


Thanks Bjorn and Jeff for the clarification!

Now the question arises how we should deal with upcoming releases of 
equinox aspects while being in incubation... ;-)


Since we published releases with versions 1.x I am not sure what the 
best way is to move on. We mentioned the incubation within the 
bundle names and download zips (according to the guidelines I hope). 
Should we go back to versions 0.x with the next releases (with some 
explanations to avoid confusion)?


-Martin





Bjorn Freeman-Benson wrote:
The policy that we've been following/enforcing is that a project in 
incubation must have releases  1.0 and that projects out of 
incubation have releases = 1.0. I apologize that this is not 
clearly written.


Jeff McAffer wrote:
In any event, Bjorn (cc'd) would certainly know if there is an 
actual policy on this.


 



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] eclipse aspects - info not weaving bundle message

[Martin Lippert]

Hi Rowan,


After much help from Heiko, I got my aspects working in standalone
equinox - thanks Heiko!


:-)


I now have a followup question. If I close the equinox framework and
then start it again, then start my java bundle (which has been
previously woven with my separate aspects bundle), this time on
starting I get this message:

[org.aspectj.osgi.service.weaving] info not weaving bundle my bundle name

And my aspects are not used.

Looking quickly in the code, this appears to be because isEnabled() is
returning false, but I can not work out why, or how to make it
'enabled'.


This is typically a visibility problem. Lets see how we can fix this.


I added the caching service and started it but this makes no
difference (not sure how to use this service anyway).

If I uninstall and re-install the aspects bundle then it starts to
work again, but I really don't want to have to do this each time.


Hm, this sounds not good. Could you type bundle no. of your woven 
bundle in the console and tell me how this looks? Is there a require 
bundle dependency to the aspects bundle? Seems like the supplementer 
mechanism doesn't work at the second startup in your setting.


How do you start the equinox framework the first and second time? Could 
you try the second start with a -Dosgi.clean=true?


-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

[Martin Lippert]

Hi Jeff,

As far as I know Martin has already verified that Equinox Aspects plays 
nicely with 3.4 and the upcoming AJDT release. I guess we will make an 
official release for 3.4 soon after 3.4 and the new AJDT are there.


Equinox Aspects currently works for 3.3 and 3.4, together with AJDT 
1.5.2, 1.5.3 and 1.6.0 (which is the development build for 3.4). But I 
agree that this should be mentioned on the website somewhere... :-)


So if there is an AJDT version or release for 3.4 available you can work 
with the existing Equinox Aspects release in 3.4. We don't not need to 
build a new release of Equinox Aspects to work with 3.4. Nevertheless it 
might be nice for marketing reasons to publish a new release shortly 
after 3.4.


What do you think?

Best regards,
-Martin





Do you have a hint where I could ask whether 1.* might be an issue in 
incubation?


Heiko


Am 14.06.2008 um 02:58 schrieb Jeff McAffer:


Heiko,

This is great.  Thanks.  some suggestions
- It would be great to have the quick start and demo somewhere in a 
permanent location on the main page.  These items will not be new 
forever and the what's new section is not where people would look to 
get started.  Perhaps a whole Getting Started bar near the top of 
the page?


- downloads.  The aspects downloads are hidden.  They are no tin the 
incubator seciton of the main Equinox download pages 
(http://download.eclipse.org/eclipse/equinox) nor are then on the 
Equinox Incubator downloads page 
(http://www.eclipse.org/equinox/incubator/downloads.php)


On a side note, I'm not 100% but there may be an issue with calling 
the Aspects stuff 1.* when it is incubation.


Other question:  Is there a 3.4 version of these facilities?

Jeff

Heiko Seeberger wrote:

Hi,

I just reworked the Equinox Incubator Aspects website. Now there is a 
detailled quick-start guide and a Hello world! demo.


We are looking forward to getting your feedback ...

Heiko
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

[Martin Lippert]

Thanks Bjorn and Jeff for the clarification!

Now the question arises how we should deal with upcoming releases of 
equinox aspects while being in incubation... ;-)


Since we published releases with versions 1.x I am not sure what the 
best way is to move on. We mentioned the incubation within the bundle 
names and download zips (according to the guidelines I hope). Should we 
go back to versions 0.x with the next releases (with some explanations 
to avoid confusion)?


-Martin





Bjorn Freeman-Benson wrote:
The policy that we've been following/enforcing is that a project in 
incubation must have releases  1.0 and that projects out of incubation 
have releases = 1.0. I apologize that this is not clearly written.


Jeff McAffer wrote:
In any event, Bjorn (cc'd) would certainly know if there is an actual 
policy on this.




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Classloader question

[Martin Lippert]

Hi Thomas!

I have converted 'jabsorb' (JSON RPC bridge) into a bundle. One of the 
things it does is that it performs unmarshalling strings actual java 
objects. When it does that, it calls Class.forName(cn) so it will use 
the defining classloader of the caller class. My question is, how can I 
make this classloader aware of classes that resides in other bundles? Is 
it at all possible or will I be forced to refrain from having jabsorb in 
a bundle and instead use a jar embedded in some other bundle with a 
wider classloader scope to make this happen?


I think you would have different options:

Option 1: DynamicImport-Package: * to the manifest of your json 
bundle. This is one possible pure OSGi solution and should do what you want.


Option 2: If you are using Equinox as OSGi implementation you could also 
take a look at the Buddy-Loading mechanism:


http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html


HTH,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] AOSGi: declare prcedence seems to have no effect

[Martin Lippert]

Hi Oren,


I'm using AOSGi and trying to define precedence between two aspects that
operate on the same join-point however it doesn't work (In one aspect I
defined 'declare precedence: B, A;' and still A's advice operates before B's
advice). Is AOSGi supposed to support 'declare precedence' at all?


Equinox Aspects should support all of the AspectJ features,
of course... ;-)

Could you open a bug report against Equinox/Incubator with [aspects] 
in the subject and maybe attach a small example to reproduce the 
problem? That would be great.


-Martin


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Untangling standard and J9 CachingService bundles

[Martin Lippert]

Hi Heiko,

to let you setup and even build equinox aspects including the J9 caching 
service you can import the project build.ibm.oti. This mocks all the 
shared classes API that is used for your workspace.


And the dependency on J9 in the standard caching feature is optional, I 
think, so you don't need a J9 for running equinox aspects with the 
standard caching service.


I agree to your comment with regards to the dynamics of the caching 
services. Would you enter a bug report for this?


HTH,
Martin


Heiko Seeberger wrote:

Hi Martin and Equinox Aspects fans,

In the current release of Equinox Aspects the standard caching service
(bundle org.aspectj.osgi.service.caching) depends on the IBM J9 VM
(import com.ibm.oti.shared.Shared). That makes it impossible for anyone
without an IBM J9 VM installed (e.g. me) to set up a working Equinox
Aspects workspace.

What do you think about the following solution?

1. Remove the dependeny:
This is easy to do (remove Activator.shouldRegister()).
Consequence: Now we might have both CachingServices registered.

2. Use service.ranking to let the IBM J9 CachingService be used in case
of both registered.
In the Activators of the both bundles we use services properties and
give the J9 CachingService a higher service.ranking.

On the long run we also should think about service dynamics: What if
someone stops the bundles providing the used CachingService?

Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: AW: [equinox-dev] Untangling standard and J9 CachingService bundles

[Martin Lippert]

Hi Heiko,


Thank you for your help. Now I can build Equinox Aspects again. Yet I am still 
wondering if I like this design :-)


I understand that, the design of this small piece is not my favorite 
one, too. ;-)


But what I like is that it allows you to install both caching bundles 
(or have both in your launch config) and let them decide which one to 
use depending on the jre they are running on. But maybe this isn't as 
nice as I think...



Yes, I will enter a bug report. And try to assign it. It's time to get familiar 
with committer tasks.


Great!

-Martin





Heiko

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Martin Lippert
Gesendet: Donnerstag, 10. April 2008 10:01
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Untangling standard and J9 CachingService bundles

Hi Heiko,

to let you setup and even build equinox aspects including the J9 caching 
service you can import the project build.ibm.oti. This mocks all the 
shared classes API that is used for your workspace.


And the dependency on J9 in the standard caching feature is optional, I 
think, so you don't need a J9 for running equinox aspects with the 
standard caching service.


I agree to your comment with regards to the dynamics of the caching 
services. Would you enter a bug report for this?


HTH,
Martin


Heiko Seeberger wrote:

Hi Martin and Equinox Aspects fans,

In the current release of Equinox Aspects the standard caching service
(bundle org.aspectj.osgi.service.caching) depends on the IBM J9 VM
(import com.ibm.oti.shared.Shared). That makes it impossible for anyone
without an IBM J9 VM installed (e.g. me) to set up a working Equinox
Aspects workspace.

What do you think about the following solution?

1. Remove the dependeny:
This is easy to do (remove Activator.shouldRegister()).
Consequence: Now we might have both CachingServices registered.

2. Use service.ranking to let the IBM J9 CachingService be used in case
of both registered.
In the Activators of the both bundles we use services properties and
give the J9 CachingService a higher service.ranking.

On the long run we also should think about service dynamics: What if
someone stops the bundles providing the used CachingService?

Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Boris Bokowski

[portal on behalf of Martin Lippert]

+1
Really great to have Boris on board for this!!!

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Heiko Seeberger has concluded successfully

[portal on behalf of Martin Lippert]

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the successful completion of
voting for Heiko Seeberger to receive full Committer status on the 
component of the eclipse.incubator project. The next step is for the PMC to
approve this vote, followed by the EMO processing the paperwork and
provisioning the account.

Vote summary: 4/0/0 with 21 pending 
   ?  John Arthorne
   ?  Oleg Besedin
   ?  Stoyan Boshev
   ?  Robert Connell
   ?  Sonia Dimitrov
   ?  Jennifer Fogell
   ?  Olivier Gruber
   ?  Ted Habeck
   ?  BJ Hargrave
   ?  Kim Horne
  +1  DJ Houghton
   ?  Simon Kaegi
   ?  Peter Kriens
   ?  Stefan Liebig
  +1  Martin Lippert
  +1  Jeff McAffer
   ?  Susan McCourt
   ?  Kim Moir
   ?  Andrew Niefer
   ?  Pascal Rapicault
   ?  Jay Rosenthal
   ?  Dave Stevenson
  +1  Thomas Watson
   ?  Matthew Webster
   ?  Ikuo Yamasaki

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] [Fwd: Vote for Committer status for Heiko Seeberger has started]

[Martin Lippert]

Hi everybody,

seems that I somehow chose the wrong predefined mailing list via the 
portal. Sorry for this... Hope it is okay to forward this here to make 
sure everybody gets it.


-Martin


 Original Message 
Subject: Vote for Committer status for Heiko Seeberger has started
Date: Fri, 21 Mar 2008 00:00:04 -0400 (EDT)
From: [EMAIL PROTECTED]  (portal on behalf of Martin Lippert)
To: [EMAIL PROTECTED]

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message signals that Martin Lippert has
nominated Heiko Seeberger as a Committer on the  component of the
eclipse.incubator project. The reason given is as follows:

Heiko has been contributing to the equinox aspects work in several
different useful ways (code, patches, discussion, e.g. #215177) over the
past few months. In particular he contributed the standard caching service
(#161202) and improved it over time (#216397), including test cases
(#221058) and discussions on it. He is also quite active on the mailing
list answering equinox aspects related questions. Combined with his
experience using equinox aspects in a large production system having Heiko
on board as a committer would be a real plus and would put equinox aspects
on more shoulders.


The vote is being held via the MyFoundation portal: voters *must* use the
portal for the votes to be properly recorded.  The voting will continue
until either all 25 existing Committers have voted or until they have been
given enough time to vote, even if they do not do so (defined as at least
one week). Heiko Seeberger must receive at least three +1s and no -1s for a
successful election.

Eligible Committers must cast their votes through their My Foundation
portal page (do NOT just reply to this email; your vote will not be
correctly recorded unless you use the portal):

http://portal.eclipse.org/

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

The project Committers eligible to vote are:

John Arthorne
Oleg Besedin
Stoyan Boshev
Robert Connell
Sonia Dimitrov
Jennifer Fogell
Olivier Gruber
Ted Habeck
BJ Hargrave
Kim Horne
DJ Houghton
Simon Kaegi
Peter Kriens
Stefan Liebig
Martin Lippert
Jeff McAffer
Susan McCourt
Kim Moir
Andrew Niefer
Pascal Rapicault
Jay Rosenthal
Dave Stevenson
Thomas Watson
Matthew Webster
Ikuo Yamasaki

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] j9 class sharing and CL.getResource

[Martin Lippert]

Hi!

I have a question regarding J9 class sharing and the adaptor hooks: I 
have an adaptor hook that uses specialized bundle file objects to 
delegate to the j9 class sharing. This implementation is done for all 
path parameters that end with .class.


Now a library that I use calls CL.getResource for a class file to get 
the bytecode of that class. In the case of j9 class sharing this call 
returns just some identifier used by j9 class sharing instead of the 
real bytecode.


Did you observe similar problems with j9 class sharing? Do you have any 
idea how to solve this?


Thanks for your help!!!

Best regards,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: AW: [equinox-dev] Equinox Aspects CachingService

[Martin Lippert]

Hi Heiko,


Great! I could get my caching service prototype running. Thanks a lot.


Sounds good. I am looking forward to your contribution and to work with 
you on improving the prototype.



Please take a look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=215177. 
Equinox Aspects 1.0.4 is not compatible with AJDT 1.5.1 / AJ 1.5.4. I already 
provided a patch.


See my comment in the bug.


Please also note, that the Bundle-Versions of org.aspectj.osgi and 
org.aspectj.osgi.service.weaving are not uptodate.


Ah, good point. Will update that asap.

Regards,
-Martin





Regards,
Heiko

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Martin Lippert
Gesendet: Samstag, 12. Januar 2008 20:51
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Equinox Aspects CachingService

Hi Heiko,


2. I wonder if AspectJAdaptor.shouldWeave() ever returns false.
I checked with a modified implementation of AspectJHook (see 1.) where 
my caching seemed to work but after loading the woven class (from cache) 
sholdWeave() returned true.
Is this magic method surely working correctly? Could anone please 
explain that first four bytes logic of shouldWeave() to me?


I analyzed this and found a possible explanation as well as a possible 
fix. The explanation can be found here:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=161202#c3

The fix is in HEAD.

4. The method ICachingService.hashNamespace() is never used externally, 
thus can be removed from the interface. Right?


Correct. Will fix this.

Best regards,
-Martin

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] AOSGi is not recognized after installing features

[Martin Lippert]

Hi Oren,


Have you tried to reproduce the bug? It is quite a limitation since I cannot
install additional plug-ins...


No, I am sorry but I haven't tried yet. Sorry for the delay, will take a 
look at it as soon as possible...


-Martin





Oren

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Lippert
Sent: Wednesday, October 24, 2007 10:11 AM
To: Equinox development mailing list
Subject: RE: [equinox-dev] AOSGi is not recognized after installing features

Hi Oren,

I will try to reproduce this to find the problem. Meanwhile you could
re-install AOSGi and everything works as expected, right?

-Martin




Hi Martin,

That's what I did:
- Installed Eclipse 3.3.1
- Added AJDT (update manager)
- Added AOSGi (unzipped last version)
- Imported demo.eclipse.tooltip and launched it -- worked as expected
- Installed Mylin (or EMF) through update manager, restarted and launched
again -- no tooltips...

Oren


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Lippert
Sent: Tuesday, October 23, 2007 4:08 PM
To: Equinox development mailing list
Subject: RE: [equinox-dev] AOSGi is not recognized after installing
features

Hi Oren,

seems like the AOSGi hook is up and running... How does the test case
looks like to reproduce this behavior?

-Martin



First, I'm testing it with demo.eclipse.tooltip.
When I launch it with the configuration Tooltip Demo (-verbose), the
console
tells:

[org.aspectj.osgi] info adding AspectJ hooks ...
[org.aspectj.osgi] info supplementing org.eclipse.jface with
[demo.eclipse.tooltip]
[org.aspectj.osgi] info supplementing org.eclipse.jface.databinding with
[demo.eclipse.tooltip]
[org.aspectj.osgi] info supplementing org.eclipse.jface.text with
[demo.eclipse.tooltip]
[org.aspectj.osgi] info supplementing org.eclipse.swt with
[demo.eclipse.tooltip]
[org.aspectj.osgi] info supplementing org.eclipse.swt.win32.win32.x86
with
[demo.eclipse.tooltip]

However, no effect is noticed and the AOSGi plug-ins do not show up in
the
installed plug-in list.

Oren

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Lippert
Sent: Tuesday, October 23, 2007 1:27 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] AOSGi is not recognized after installing
features

Hi Oren,


First, I would like to let you know that AOSGi is functioning on
Eclipse
3.3.1.

Great to hear!!!

Regarding your problem: What does the OSGi console short status tells
you?
Are the AOSGi bundles part of that list?

-Martin



Yet, I'm facing a weird problem:

When I'm adding a feature to Eclipse 3.3.1 (using update manager),
after
restarting Eclipse the AOSGi plug-ins are not recognized (they don't
show
up
in the installed plug-ins list and of course AOSGi is not functioning).
This
happened to me when I tried to add EMF and also Mylin. I tried the
-clean
flag and the problem remains. Moreover, even when restoring the
previous
Eclipse state the problem remains. This happens only when the features
are
added AFTER AOSGi; when AOSGi is added after the features everything
works
fine. any suggestions?



Thanks,

Oren



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Oleg Besedin

[portal on behalf of Martin Lippert]

+1
This is where you enter your comments about the candidate and you explain
why you are voting +1, 0, or -1.

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] AOSGi for Eclipse 3.3

[Martin Lippert]

Hi,

 I am not aware of any changes to the framework that would prevent AOSGi
 from working on 3.3.  Matthew or Martin have you tested 3.3 with AOSGi
 yet?

Nope, haven't tested AOSGi on 3.3 yet... Matthew?

-Martin




 Tom




 Oren Mishali [EMAIL PROTECTED]
 Sent by: [EMAIL PROTECTED]
 07/17/2007 07:47 AM
 Please respond to
 Equinox development mailing list equinox-dev@eclipse.org


 To
 'Equinox development mailing list' equinox-dev@eclipse.org
 cc

 Subject
 [equinox-dev] AOSGi for Eclipse 3.3






 Hi,

 I am currently using AOSGi with Eclipse 3.2.*. Is it compatible with
 Eclipse 3.3.*?
 If not, when will it be available?

 Thanks,
 Oren___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev