Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Providing a callback to an OSGi bundle

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 <tjwatson@xxxxxxxxxx> 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



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" <samindaa@xxxxxxxxx>

To:

"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>

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 <tjwatson@xxxxxxxxxx> 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" <samindaa@xxxxxxxxx>

To:

equinox-dev@xxxxxxxxxxx

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@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/equinox-dev


    _______________________________________________
    equinox-dev mailing list

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



--
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. -
www.wso2.org _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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




--
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

GIF image

GIF image

GIF image

GIF image


Back to the top