The eclipse buddy policies have a number of issues. For example, when multiple versions of bundles exist it is random which version your buddy will be. Also if multiple versions of a package exist in the framework there is a potential for class space inconsistencies. Supporting legacy code and defining a concise modular framework do not always go hand in hand. Many folks in OSGi like to call these kinds of "features" in eclipse as "legacy hacks". To a certain extent I can agree, but at this point no one has come up with a better solution that requires *no* change to the legacy code to make it work in an OSGi modular environment.
In OSGi we would like to spec some solution to to help support legacy code
that uses Class.forName and the context class loader in OSGi to find
extensions. For many cases buddy class loading works nicely, but at this
point the buddy class loading mechanism has too many limitations to be
considered for the OSGi specification.
Tom
From: "Saminda Abeyruwan" <[EMAIL PROTECTED]>
To: "Equinox development mailing list" <equinox-dev@eclipse.org>
Date: 04/17/2008 11:36 AM
Subject: Re: [equinox-dev] Providing a callback to an OSGi bundle
Dear Tom,
Thank you for the swift reply.
What you have suggested solved the entire problem. I used
Eclipse-BuddyPolicy, and Eclipse-RegisterBuddy
bundle manifest headers to get more control over wiring buddies.
I was wondering is there a provision to standardize these bundle manifest
headers in future OSGi specification. IMO this would be a very important
extension to have in OSGi spec.
Thank you!
Saminda
On Thu, Apr 17, 2008 at 7:02 PM, Thomas Watson <[EMAIL PROTECTED]> wrote:
How do you know the Bundle where the configuration file is and how do you
read it from Bundle B? I assume you must be getting the Bundle object for
B somehow and using Bundle.getEntry to find the configuration file. If
that is the case you can just call Bundle.loadClass(String name) on the
bundle that has the configuration file.
But we must be missing something from your scenario because you say you
are working with existing code that I assume knows nothing about OSGi,
otherwise you would use services like you said. For legacy code that
needs access to implementation class from other bundles that depend on it
you can use the eclipse buddy class loading mechanism. Adding the
following header to Bundle A's manifest will allow Bundle B (and any
other bundle that depends on A) to become a buddy to Bundle A.
Eclipse-BuddyPolicy: dependent
Tom
Inactive hide details for "Saminda Abeyruwan" ---04/17/2008 04:27:46
AM---Hi Devs,"Saminda Abeyruwan" ---04/17/2008 04:27:46 AM---Hi Devs,
From: "Saminda Abeyruwan" <[EMAIL PROTECTED]>
To: equinox-dev@eclipse.org
Date: 04/17/2008 04:27 AM
Subject: [equinox-dev] Providing a callback to an OSGi bundle
Hi Devs,
I have faced with a use-case where a callback need to be passed to an
OSGi bundle.
Scenario:
Bundle A exports package "x.y" and "a.b". These are the only packages it
exports. The logic of this bundle is such that it can populate a
callback, when some function is finished. Say this callback should
implement interface "x.y.Foo". Required callbacks are written in a
configuration file, and which will be located using OSGi infrastructure.
There exist another bundle B, which has classes that implemented the
interface "x.y.Foo" say "x.y.K.FooImpl1" and that bundle also contains
the configuration file listing the QName of the impl classes. This bundle
imports package "x.y".
When bundle A reads the configuration files from bundle B and tries to
initiate the impl classes, bundle A would failed with class definition
not found exception stating that it can't locate the implementation
"x.y.k.FooImpl1". This is obvious because bundle A does not import
package "x.y.k".
Implementation to a callback can contain any package. Thus, bundle A
needs to export this some way. Java itself provides callback mechanisms
and implementations are done by the users.
Is there any way to solve prior problem. Is it possible me to say in
bundle A's MANIFEST.MF Export-Packaget : x.y, a.b, *;
resolution:=optional. Is there a way to solve this callback issue using
package admin.
My problem with callback would have been solved using OSGi services.
Since I've to work with an existing code, OSGi service wouldn't be
suffix.
Thank you!
Saminda
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org _______________________________________________
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
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org _______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: 0A710036.gif>>
<<inline: 0A981046.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
