Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #82835] |
Mon, 05 February 2007 18:10 |
Eclipse User |
|
|
|
Originally posted by: 9simmend.informatik.uni-hamburg.de
I've got a bit of a confusion when i read this new wiki page.
http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhan cements
Is the new Buddymechanism now the Bundle-BuddyPolicy or still the old
one. I tried the new mechanism and it didn't worked under 3.2.1.
so i used the old naming.
Now i tried a test and i wonder if it is a bug or just a missunderstanding.
i wrote 4 plugins. A,B,C,D
A and B are representing the generic bundles A is pure OSGI B is a
eclipse Plugin with.
C and D are respectively the enhancing Plugins that got classes A and B
need to load.
the problem is that A finds C's classes but not D's, B doesnt find any.
if i do include the DynamicImport-Package: * statement everything works
fine.
any conclusions ?????
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #82939 is a reply to message #82835] |
Tue, 06 February 2007 12:18 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
The Bundle-BuddyPolicy was added in OSGi 4.1, so it's in 3.3 but not in 3.2 (and won't be in 3.2). If you need 3.2 support, you should use Eclipse-BuddyPolicy. Of course, you can guarantee correctness by using both :-)
The Dynamic-ImportPackage will do lookup each time; using ImportPackage does the wiring when the bundle is resolved. Would you not be better off with ImportPackage?
Alex.
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #82984 is a reply to message #82939] |
Tue, 06 February 2007 14:16 |
Eclipse User |
|
|
|
Originally posted by: 9simmend.informatik.uni-hamburg.de
Alex Blewitt schrieb:
> The Bundle-BuddyPolicy was added in OSGi 4.1, so it's in 3.3 but not in 3.2 (and won't be in 3.2). If you need 3.2 support, you should use Eclipse-BuddyPolicy. Of course, you can guarantee correctness by using both :-)
>
> The Dynamic-ImportPackage will do lookup each time; using ImportPackage does the wiring when the bundle is resolved. Would you not be better off with ImportPackage?
>
> Alex.
The Problem could be described as:
There is a Simulationenvironmen for petrinets with possible java
inscriptions in the nets. I want to use OSGI to install a Bundle XY
which contains the nets and some Javaclasses the nets use. So the bundle
is installed and has a imports on the core bundle containing the
packages with the net semantic. Additionally there are different
formalism that give the netmodel a semantic, in other words a formalism
compiles the nets. So the Formalism Bundle needs to see the Javaclasses
with Class.forName(). Because of the generality of formalism and
simulator core packages i can't import or require that bundle. This case
is therefor the same like the appender-log4j situation.
My current approach is to use services in that XY Bundle to offer the
compiled Nets to the Simulation Engine. The Compiling is also offered by
Service from the Formalism bundles. The information which formalism has
to be used is saved in the Serialized Nets in Bundle XY.
The whole Idea is to define some Workflownets controlling data and
controlflow of some other bundles in a experimental environment written
for the eclipse IDE.
but back to my question.
i just can't figure out why the buddy mechanism won't works for
accessing classes from equinox bundles to eclipse plugins. ithought it
is the same resolving mechanism for both.
Could it be that i use a wrongly configurated target Platform?? may be
the duplication of the running core. ??
to the missunderstanding of Buddy vs Bundle, may be the wiki page
should advise to that.
greets Felix
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #83087 is a reply to message #82984] |
Tue, 06 February 2007 23:12 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
If you want to read up about what they do, I suggest that you get hold of a copy of the OSGi spec from www.osgi.org (last time I was there, you had to put in an e-mail address to receive the location for where to download them) which goes into this in excruciating detail.
Equinox is one OSGi engine, but they are others and they all follow the same model when it comes to wiring up bundles. I don't know exactly how your system is laid out or how you want to hook things up, so I can only recommend that you read that.
I also put a brief bit on the classloading and buddy module at http://www.eclipsezone.com/articles/eclipse-vms/ a while ago, but chances are it won't tell you anything you don't know.
But do remember -- in Eclispe 3.2, it's Eclipse-BuddyPolicy and Eclipse-RegisterBuddy. It won't be the Bundle- variants until Eclipse 3.3 and OSGi 4.1 is released.
Alex.
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #83117 is a reply to message #83087] |
Thu, 08 February 2007 18:51 |
Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Are the OSGi 4.1 spec docs available? If so, where? Only 4.0.1 seems
to be available here:
http://www.osgi.org/osgi_technology/download_specs.asp?secti on=2#Release4
Is the 4.1 work only available to members or something?
Thanks,
Scott
Alex Blewitt wrote:
> If you want to read up about what they do, I suggest that you get hold of a copy of the OSGi spec from www.osgi.org (last time I was there, you had to put in an e-mail address to receive the location for where to download them) which goes into this in excruciating detail.
>
> Equinox is one OSGi engine, but they are others and they all follow the same model when it comes to wiring up bundles. I don't know exactly how your system is laid out or how you want to hook things up, so I can only recommend that you read that.
>
> I also put a brief bit on the classloading and buddy module at http://www.eclipsezone.com/articles/eclipse-vms/ a while ago, but chances are it won't tell you anything you don't know.
>
> But do remember -- in Eclispe 3.2, it's Eclipse-BuddyPolicy and Eclipse-RegisterBuddy. It won't be the Bundle- variants until Eclipse 3.3 and OSGi 4.1 is released.
>
> Alex.
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #83174 is a reply to message #83087] |
Fri, 09 February 2007 12:52 |
Eclipse User |
|
|
|
Originally posted by: 9simmend.informatik.uni-hamburg.de
Alex Blewitt schrieb:
> If you want to read up about what they do, I suggest that you get hold of a copy of the OSGi spec from www.osgi.org (last time I was there, you had to put in an e-mail address to receive the location for where to download them) which goes into this in excruciating detail.
>
> Equinox is one OSGi engine, but they are others and they all follow the same model when it comes to wiring up bundles. I don't know exactly how your system is laid out or how you want to hook things up, so I can only recommend that you read that.
>
> I also put a brief bit on the classloading and buddy module at http://www.eclipsezone.com/articles/eclipse-vms/ a while ago, but chances are it won't tell you anything you don't know.
>
> But do remember -- in Eclispe 3.2, it's Eclipse-BuddyPolicy and Eclipse-RegisterBuddy. It won't be the Bundle- variants until Eclipse 3.3 and OSGi 4.1 is released.
>
> Alex.
I just found out the problems i got with the buddy loading mechanism.
Is this correct?
Bundles A and B. A needs help for loading classes and B is a Buddy of A.
now if there isnt a import or required dependency from B to A.
Buddyloading mechanism won't work.
Felix
|
|
|
|
|
Re: Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy [message #86083 is a reply to message #83496] |
Wed, 04 April 2007 11:49 |
Eclipse User |
|
|
|
Originally posted by: scott.anderson.missionmode.com
On 2007-02-18 12:53:58 -0500, Martin Dames <m.dames@gmx.de> said:
> The funny thing is, that nowhere is mentioned a Bundle-Buddy Policy in
> R4.1? I thought the Buddy Policy technique is adobted from OSGi in R4.1?
>
> Or am I missing something?
A quick browse through the source code in the eclipse CVS viewer shows
that the Buddy-Policy headers don't seem to show up (this is in the
head revision of org.eclipse.osgi... Alex, are you sure that this is
implemented in 3.3/4.1?
-s
|
|
|
|
Powered by
FUDForum. Page generated in 0.02705 seconds