Dear Tom, Thank you again for swift reply.
Now I clearly understand the situation. As you have mentioned, supporting legacy code and defining a modular framework has trade-offs. Good news is, considering the scope and constraints of my application , buddy class loading is work nicely for me. Thank you! Saminda On Thu, Apr 17, 2008 at 10:59 PM, Thomas Watson <[EMAIL PROTECTED]> wrote: > 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 > > > > [image: Inactive hide details for "Saminda Abeyruwan" ---04/17/2008 > 11:36:18 AM---Dear Tom,]"Saminda Abeyruwan" ---04/17/2008 11:36:18 > AM---Dear 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]<[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 > > > > [image: 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] <[EMAIL PROTECTED]>> > To:* > [EMAIL PROTECTED] <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* <http://www.wso2.org/> > _______________________________________________ > equinox-dev mailing list* > [EMAIL PROTECTED] <equinox-dev@eclipse.org>* > > **https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> > > > _______________________________________________ > equinox-dev mailing list* > [EMAIL PROTECTED] <equinox-dev@eclipse.org>* > > **https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> > > > > > -- > Saminda Abeyruwan > > Senior Software Engineer > WSO2 Inc. - *www.wso2.org* <http://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
<<ecblank.gif>>
<<0A710036.gif>>
<<0A981046.gif>>
<<graycol.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
