You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Marco หงุ่ยตระกูล-Schulze <Ma...@NightLabs.de> on 2010/05/06 19:09:46 UTC
Buddy class loading supported?
Hello *,
I'm new to Felix but use Eclipse already for a few years. Equinox
supports so-called buddy-class-loading. Does Felix have such a feature,
too? If so, how is it named? I looked for "felix buddy class loading",
but didn't find anything. Is it maybe simply called differently?
If it is not clear to you, what I mean by "buddy class loading", imagine
you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
a framework and my.bundle.b some implementation for it. Thus,
my.bundle.b would define a dependency on my.bundle.a (to import the
interfaces that are provided by the framework), but my.bundle.a would
know nothing about my.bundle.b.
There are situations (especially when integrating non-OSGi-aware systems
into an OSGi context), when the framework in my.bundle.a wants to
instantiate a class from my.bundle.b, but this is not possible as
there's no dependency in this direction. Thus, my.bundle.a would get a
ClassNotFoundException when taking the class name (that was maybe
somehow added to a configuration by my.bundle.b) and trying a
Class.forName(...).
Here comes buddy-class-loading into play: my.bundle.a would say that it
supports it by the following entry in its MANIFEST.MF:
Eclipse-BuddyPolicy: registered
my.bundle.b would declare a dependency on my.bundle.b and say that its
own classes should be available to my.bundle.a by having these two
entries in its MANIFEST.MF:
Require-Bundle: my.bunde.a
Eclipse-RegisterBuddy: my.bunde.a
The important thing is that my.bundle.a still does not reference
my.bundle.b anywhere (the framework must of course not know any of its
implementations), but is still able to load the (exported) classes from
my.bundle.b.
Further information about buddy class loading can be found here:
https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
http://www.eclipsezone.com/articles/eclipse-vms/
Best regards, Marco :-)
Re: Buddy class loading supported?
Posted by André Dietisheim <an...@trialox.org>.
Hi Marco
I'm a long term equinox (Eclipse RCP) user and I perfectly know this
proprietary equinox feautre. To be honest I'd argue that if you need
this feature you most probably organized your dependency in a
non-optimal manner or even have a design issue. I used buddy policies in
my first osgi app and could always replace it by services / extension
points in later projects. It's most probably just a matter or organizing
your dependencies right or use services / extension-points right.
Furthermore I'd argue that using buddy policies are generally thougth as
non-optimal practice and should be avoided. Equinox implemented it to
allow a slow migration from Eclipse <3.0 plugin architecture towards OSGI.
Cheers
André
On 05/06/2010 08:06 PM, Marco หงุ่ยตระกูล-Schulze wrote:
> Hi Richard,
>
> thanks a lot for this quick response! Is it planned to implement buddy
> class loading, soon? After some more research, I stumbled over the issue
> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
> open for about 4 years already.
>
> Best regards, Marco :-)
>
>
> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>
>> No, sorry, Felix doesn't support such a mechanism.
>>
>> -> richard
>>
>> On 5/6/10 13:09, Marco หงุ่ยตระกูล-Schulze wrote:
>>
>>> Hello *,
>>>
>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>> but didn't find anything. Is it maybe simply called differently?
>>>
>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>> a framework and my.bundle.b some implementation for it. Thus,
>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>> interfaces that are provided by the framework), but my.bundle.a would
>>> know nothing about my.bundle.b.
>>>
>>> There are situations (especially when integrating non-OSGi-aware systems
>>> into an OSGi context), when the framework in my.bundle.a wants to
>>> instantiate a class from my.bundle.b, but this is not possible as
>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>> ClassNotFoundException when taking the class name (that was maybe
>>> somehow added to a configuration by my.bundle.b) and trying a
>>> Class.forName(...).
>>>
>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>> supports it by the following entry in its MANIFEST.MF:
>>>
>>> Eclipse-BuddyPolicy: registered
>>>
>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>> own classes should be available to my.bundle.a by having these two
>>> entries in its MANIFEST.MF:
>>>
>>> Require-Bundle: my.bunde.a
>>> Eclipse-RegisterBuddy: my.bunde.a
>>>
>>> The important thing is that my.bundle.a still does not reference
>>> my.bundle.b anywhere (the framework must of course not know any of its
>>> implementations), but is still able to load the (exported) classes from
>>> my.bundle.b.
>>>
>>> Further information about buddy class loading can be found here:
>>>
>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>
>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>
>>> Best regards, Marco :-)
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Christopher Armstrong <ca...@fastmail.com.au>.
Hi Donald
You can register the factories as services from the same bundle, but
using the whiteboard pattern pick up the services from that bundle
plus other bundles, which gives you the flexibility to add services at
a later date.
It is always possible to refactor the code later to then put some of
the factories in their own bundles.
Cheers
Chris
On 13/05/2010, at 04:48 AM, Donald Whytock wrote:
> After thinking about it further, I have to ask: While, yes, it's
> possible to kick off multiple factories from a single bundle, isn't it
> logical to have a factory and the services it generates in its own
> bundle, so it can be easily swapped out and tested?
>
> Does the sheer number of bundles make a difference at some point, to
> where it's better to consolidate a bunch of bundles into one for
> runtime efficiency?
>
> Don
>
> 2010/5/11 Donald Whytock <dw...@gmail.com>:
>> Actually, after a week of playing with it, I find I have something
>> similar to the ManagedServiceFactory principle.
>>
>> You're right, worrying about the GenericActivator is beside the
>> point.
>> It should be something as simple as
>>
>> ServiceTool.registerFactory(factoryinstance, factoryname);
>>
>> MyService service = ServiceTool.getService(factoryname, servicename);
>>
>> MyService service = ServiceTool.makeService(factoryname, servicename,
>> properties);
>>
>> Though I would still kinda like to see
>>
>> ServiceTool.makeServices(factoryinstance, factoryname, propertysets);
>>
>> to make a bunch of service instances at once without necessarily
>> making an active factory.
>>
>> Don
>>
>> On Tue, May 11, 2010 at 12:04 PM, Peter Kriens <peter.kriens@aqute.biz
>> > wrote:
>>> I looked a bit at your code.
>>>
>>> I think you mix concerns in your GenericActivator. A model for
>>> factories unrelated to activating services. It would be better to
>>> split these different concepts and provide a utility for the
>>> factory model. For example, a bundle could have multiple service
>>> factories but it can have only one activator. Usually a clear sign
>>> of lack of cohesion. In your case I would register a
>>> ManagedServiceFactory and then register a service of my type for
>>> each record that I get. This is hardly any code, incredibly
>>> robust, and is to manage during runtime by creating new
>>> configurations. This is likely a lot easier than what you do now.
>>>
>>> Services are extremely powerful, if you feel the need to invent a
>>> framework on top of OSGi about services, do not hesitate to bounce
>>> your ideas on this list.
>>>
>>> Anyway, buddy class loading is not needed in this circumstance,
>>> you're lucky Felix does not have it. Though buddy class loading
>>> works most of the time, it is basically an attempt to crawl back
>>> to the linear classpath and its JAR hell.
>>>
>>> Hope this helps, kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 6 mei 2010, at 22:33, Donald Whytock wrote:
>>>
>>>> I wound up having to create a factory in bundle.b that's an
>>>> extension
>>>> of a class in bundle.a. The bundle.b subclass would override a
>>>> method
>>>> for providing an instantiation of the desired class. I had to
>>>> instantiate the factory in bundle.b and pass it to bundle.a. That
>>>> lets bundle.a crank out the class defined in bundle.b without the
>>>> bundle.b class definition.
>>>>
>>>> Close to putting out a .jar, but there's an example of it at
>>>>
>>>> http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
>>>>
>>>> Don
>>>>
>>>> On Thu, May 6, 2010 at 3:28 PM, Richard S. Hall <heavy@ungoverned.org
>>>> > wrote:
>>>>> On 5/6/10 14:06, Marco หงุ่ยตระกูล-Schulze
>>>>> wrote:
>>>>>>
>>>>>> Hi Richard,
>>>>>>
>>>>>> thanks a lot for this quick response! Is it planned to
>>>>>> implement buddy
>>>>>> class loading, soon? After some more research, I stumbled over
>>>>>> the issue
>>>>>> https://issues.apache.org/jira/browse/FELIX-42 which mentions
>>>>>> it, but is
>>>>>> open for about 4 years already.
>>>>>>
>>>>>
>>>>> I don't think so. There are issues around implementing this as a
>>>>> general
>>>>> mechanism that cannot be resolved, so we've just not progressed
>>>>> on it.
>>>>> Generally speaking, we end up coming up with case-by-case
>>>>> solutions when we
>>>>> run into scenarios needing such capabilities.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> Best regards, Marco :-)
>>>>>>
>>>>>>
>>>>>> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>>>>>>
>>>>>>>
>>>>>>> No, sorry, Felix doesn't support such a mechanism.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>> On 5/6/10 13:09, Marco หงุ่ยตระกูล-
>>>>>>> Schulze wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hello *,
>>>>>>>>
>>>>>>>> I'm new to Felix but use Eclipse already for a few years.
>>>>>>>> Equinox
>>>>>>>> supports so-called buddy-class-loading. Does Felix have such
>>>>>>>> a feature,
>>>>>>>> too? If so, how is it named? I looked for "felix buddy class
>>>>>>>> loading",
>>>>>>>> but didn't find anything. Is it maybe simply called
>>>>>>>> differently?
>>>>>>>>
>>>>>>>> If it is not clear to you, what I mean by "buddy class
>>>>>>>> loading", imagine
>>>>>>>> you have two plugins: my.bundle.a and my.bundle.b.
>>>>>>>> my.bundle.a contains
>>>>>>>> a framework and my.bundle.b some implementation for it. Thus,
>>>>>>>> my.bundle.b would define a dependency on my.bundle.a (to
>>>>>>>> import the
>>>>>>>> interfaces that are provided by the framework), but
>>>>>>>> my.bundle.a would
>>>>>>>> know nothing about my.bundle.b.
>>>>>>>>
>>>>>>>> There are situations (especially when integrating non-OSGi-
>>>>>>>> aware systems
>>>>>>>> into an OSGi context), when the framework in my.bundle.a
>>>>>>>> wants to
>>>>>>>> instantiate a class from my.bundle.b, but this is not
>>>>>>>> possible as
>>>>>>>> there's no dependency in this direction. Thus, my.bundle.a
>>>>>>>> would get a
>>>>>>>> ClassNotFoundException when taking the class name (that was
>>>>>>>> maybe
>>>>>>>> somehow added to a configuration by my.bundle.b) and trying a
>>>>>>>> Class.forName(...).
>>>>>>>>
>>>>>>>> Here comes buddy-class-loading into play: my.bundle.a would
>>>>>>>> say that it
>>>>>>>> supports it by the following entry in its MANIFEST.MF:
>>>>>>>>
>>>>>>>> Eclipse-BuddyPolicy: registered
>>>>>>>>
>>>>>>>> my.bundle.b would declare a dependency on my.bundle.b and say
>>>>>>>> that its
>>>>>>>> own classes should be available to my.bundle.a by having
>>>>>>>> these two
>>>>>>>> entries in its MANIFEST.MF:
>>>>>>>>
>>>>>>>> Require-Bundle: my.bunde.a
>>>>>>>> Eclipse-RegisterBuddy: my.bunde.a
>>>>>>>>
>>>>>>>> The important thing is that my.bundle.a still does not
>>>>>>>> reference
>>>>>>>> my.bundle.b anywhere (the framework must of course not know
>>>>>>>> any of its
>>>>>>>> implementations), but is still able to load the (exported)
>>>>>>>> classes from
>>>>>>>> my.bundle.b.
>>>>>>>>
>>>>>>>> Further information about buddy class loading can be found
>>>>>>>> here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>>>>>>
>>>>>>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>>>>>>
>>>>>>>> Best regards, Marco :-)
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--------
Christopher Armstrong
carmstrong@fastmail.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Donald Whytock <dw...@gmail.com>.
After thinking about it further, I have to ask: While, yes, it's
possible to kick off multiple factories from a single bundle, isn't it
logical to have a factory and the services it generates in its own
bundle, so it can be easily swapped out and tested?
Does the sheer number of bundles make a difference at some point, to
where it's better to consolidate a bunch of bundles into one for
runtime efficiency?
Don
2010/5/11 Donald Whytock <dw...@gmail.com>:
> Actually, after a week of playing with it, I find I have something
> similar to the ManagedServiceFactory principle.
>
> You're right, worrying about the GenericActivator is beside the point.
> �It should be something as simple as
>
> ServiceTool.registerFactory(factoryinstance, factoryname);
>
> MyService service = ServiceTool.getService(factoryname, servicename);
>
> MyService service = ServiceTool.makeService(factoryname, servicename,
> properties);
>
> Though I would still kinda like to see
>
> ServiceTool.makeServices(factoryinstance, factoryname, propertysets);
>
> to make a bunch of service instances at once without necessarily
> making an active factory.
>
> Don
>
> On Tue, May 11, 2010 at 12:04 PM, Peter Kriens <pe...@aqute.biz> wrote:
>> I looked a bit at your code.
>>
>> I think you mix concerns in your GenericActivator. A model for factories unrelated to activating services. It would be better to split these different concepts and provide a utility for the factory model. For example, a bundle could have multiple service factories but it can have only one activator. Usually a clear sign of lack of cohesion. In your case I would register a ManagedServiceFactory and then register a service of my type for each record that I get. This is hardly any code, incredibly robust, and is to manage during runtime by creating new configurations. This is likely a lot easier than what you do now.
>>
>> Services are extremely powerful, if you feel the need to invent a framework on top of OSGi about services, do not hesitate to bounce your ideas on this list.
>>
>> Anyway, buddy class loading is not needed in this circumstance, you're lucky Felix does not have it. Though buddy class loading works most of the time, it is basically an attempt to crawl back to the linear classpath and its JAR hell.
>>
>> Hope this helps, kind regards,
>>
>> � � � �Peter Kriens
>>
>>
>>
>>
>>
>>
>> On 6 mei 2010, at 22:33, Donald Whytock wrote:
>>
>>> I wound up having to create a factory in bundle.b that's an extension
>>> of a class in bundle.a. �The bundle.b subclass would override a method
>>> for providing an instantiation of the desired class. �I had to
>>> instantiate the factory in bundle.b and pass it to bundle.a. �That
>>> lets bundle.a crank out the class defined in bundle.b without the
>>> bundle.b class definition.
>>>
>>> Close to putting out a .jar, but there's an example of it at
>>>
>>> http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
>>>
>>> Don
>>>
>>> On Thu, May 6, 2010 at 3:28 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>>>> On 5/6/10 14:06, Marco ˧��µ�С��-Schulze wrote:
>>>>>
>>>>> Hi Richard,
>>>>>
>>>>> thanks a lot for this quick response! Is it planned to implement buddy
>>>>> class loading, soon? After some more research, I stumbled over the issue
>>>>> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
>>>>> open for about 4 years already.
>>>>>
>>>>
>>>> I don't think so. There are issues around implementing this as a general
>>>> mechanism that cannot be resolved, so we've just not progressed on it.
>>>> Generally speaking, we end up coming up with case-by-case solutions when we
>>>> run into scenarios needing such capabilities.
>>>>
>>>> -> richard
>>>>
>>>>> Best regards, Marco :-)
>>>>>
>>>>>
>>>>> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>>>>>
>>>>>>
>>>>>> No, sorry, Felix doesn't support such a mechanism.
>>>>>>
>>>>>> -> �richard
>>>>>>
>>>>>> On 5/6/10 13:09, Marco ˧��µ�С��-Schulze wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello *,
>>>>>>>
>>>>>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>>>>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>>>>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>>>>>> but didn't find anything. Is it maybe simply called differently?
>>>>>>>
>>>>>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>>>>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>>>>>> a framework and my.bundle.b some implementation for it. Thus,
>>>>>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>>>>>> interfaces that are provided by the framework), but my.bundle.a would
>>>>>>> know nothing about my.bundle.b.
>>>>>>>
>>>>>>> There are situations (especially when integrating non-OSGi-aware systems
>>>>>>> into an OSGi context), when the framework in my.bundle.a wants to
>>>>>>> instantiate a class from my.bundle.b, but this is not possible as
>>>>>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>>>>>> ClassNotFoundException when taking the class name (that was maybe
>>>>>>> somehow added to a configuration by my.bundle.b) and trying a
>>>>>>> Class.forName(...).
>>>>>>>
>>>>>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>>>>>> supports it by the following entry in its MANIFEST.MF:
>>>>>>>
>>>>>>> Eclipse-BuddyPolicy: registered
>>>>>>>
>>>>>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>>>>>> own classes should be available to my.bundle.a by having these two
>>>>>>> entries in its MANIFEST.MF:
>>>>>>>
>>>>>>> Require-Bundle: my.bunde.a
>>>>>>> Eclipse-RegisterBuddy: my.bunde.a
>>>>>>>
>>>>>>> The important thing is that my.bundle.a still does not reference
>>>>>>> my.bundle.b anywhere (the framework must of course not know any of its
>>>>>>> implementations), but is still able to load the (exported) classes from
>>>>>>> my.bundle.b.
>>>>>>>
>>>>>>> Further information about buddy class loading can be found here:
>>>>>>>
>>>>>>>
>>>>>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>>>>>
>>>>>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>>>>>
>>>>>>> Best regards, Marco :-)
>>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Donald Whytock <dw...@gmail.com>.
Actually, after a week of playing with it, I find I have something
similar to the ManagedServiceFactory principle.
You're right, worrying about the GenericActivator is beside the point.
It should be something as simple as
ServiceTool.registerFactory(factoryinstance, factoryname);
MyService service = ServiceTool.getService(factoryname, servicename);
MyService service = ServiceTool.makeService(factoryname, servicename,
properties);
Though I would still kinda like to see
ServiceTool.makeServices(factoryinstance, factoryname, propertysets);
to make a bunch of service instances at once without necessarily
making an active factory.
Don
On Tue, May 11, 2010 at 12:04 PM, Peter Kriens <pe...@aqute.biz> wrote:
> I looked a bit at your code.
>
> I think you mix concerns in your GenericActivator. A model for factories unrelated to activating services. It would be better to split these different concepts and provide a utility for the factory model. For example, a bundle could have multiple service factories but it can have only one activator. Usually a clear sign of lack of cohesion. In your case I would register a ManagedServiceFactory and then register a service of my type for each record that I get. This is hardly any code, incredibly robust, and is to manage during runtime by creating new configurations. This is likely a lot easier than what you do now.
>
> Services are extremely powerful, if you feel the need to invent a framework on top of OSGi about services, do not hesitate to bounce your ideas on this list.
>
> Anyway, buddy class loading is not needed in this circumstance, you're lucky Felix does not have it. Though buddy class loading works most of the time, it is basically an attempt to crawl back to the linear classpath and its JAR hell.
>
> Hope this helps, kind regards,
>
> � � � �Peter Kriens
>
>
>
>
>
>
> On 6 mei 2010, at 22:33, Donald Whytock wrote:
>
>> I wound up having to create a factory in bundle.b that's an extension
>> of a class in bundle.a. �The bundle.b subclass would override a method
>> for providing an instantiation of the desired class. �I had to
>> instantiate the factory in bundle.b and pass it to bundle.a. �That
>> lets bundle.a crank out the class defined in bundle.b without the
>> bundle.b class definition.
>>
>> Close to putting out a .jar, but there's an example of it at
>>
>> http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
>>
>> Don
>>
>> On Thu, May 6, 2010 at 3:28 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>>> On 5/6/10 14:06, Marco ˧��µ�С��-Schulze wrote:
>>>>
>>>> Hi Richard,
>>>>
>>>> thanks a lot for this quick response! Is it planned to implement buddy
>>>> class loading, soon? After some more research, I stumbled over the issue
>>>> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
>>>> open for about 4 years already.
>>>>
>>>
>>> I don't think so. There are issues around implementing this as a general
>>> mechanism that cannot be resolved, so we've just not progressed on it.
>>> Generally speaking, we end up coming up with case-by-case solutions when we
>>> run into scenarios needing such capabilities.
>>>
>>> -> richard
>>>
>>>> Best regards, Marco :-)
>>>>
>>>>
>>>> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>>>>
>>>>>
>>>>> No, sorry, Felix doesn't support such a mechanism.
>>>>>
>>>>> -> �richard
>>>>>
>>>>> On 5/6/10 13:09, Marco ˧��µ�С��-Schulze wrote:
>>>>>
>>>>>>
>>>>>> Hello *,
>>>>>>
>>>>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>>>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>>>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>>>>> but didn't find anything. Is it maybe simply called differently?
>>>>>>
>>>>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>>>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>>>>> a framework and my.bundle.b some implementation for it. Thus,
>>>>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>>>>> interfaces that are provided by the framework), but my.bundle.a would
>>>>>> know nothing about my.bundle.b.
>>>>>>
>>>>>> There are situations (especially when integrating non-OSGi-aware systems
>>>>>> into an OSGi context), when the framework in my.bundle.a wants to
>>>>>> instantiate a class from my.bundle.b, but this is not possible as
>>>>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>>>>> ClassNotFoundException when taking the class name (that was maybe
>>>>>> somehow added to a configuration by my.bundle.b) and trying a
>>>>>> Class.forName(...).
>>>>>>
>>>>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>>>>> supports it by the following entry in its MANIFEST.MF:
>>>>>>
>>>>>> Eclipse-BuddyPolicy: registered
>>>>>>
>>>>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>>>>> own classes should be available to my.bundle.a by having these two
>>>>>> entries in its MANIFEST.MF:
>>>>>>
>>>>>> Require-Bundle: my.bunde.a
>>>>>> Eclipse-RegisterBuddy: my.bunde.a
>>>>>>
>>>>>> The important thing is that my.bundle.a still does not reference
>>>>>> my.bundle.b anywhere (the framework must of course not know any of its
>>>>>> implementations), but is still able to load the (exported) classes from
>>>>>> my.bundle.b.
>>>>>>
>>>>>> Further information about buddy class loading can be found here:
>>>>>>
>>>>>>
>>>>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>>>>
>>>>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>>>>
>>>>>> Best regards, Marco :-)
>>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Peter Kriens <pe...@aqute.biz>.
I looked a bit at your code.
I think you mix concerns in your GenericActivator. A model for factories unrelated to activating services. It would be better to split these different concepts and provide a utility for the factory model. For example, a bundle could have multiple service factories but it can have only one activator. Usually a clear sign of lack of cohesion. In your case I would register a ManagedServiceFactory and then register a service of my type for each record that I get. This is hardly any code, incredibly robust, and is to manage during runtime by creating new configurations. This is likely a lot easier than what you do now.
Services are extremely powerful, if you feel the need to invent a framework on top of OSGi about services, do not hesitate to bounce your ideas on this list.
Anyway, buddy class loading is not needed in this circumstance, you're lucky Felix does not have it. Though buddy class loading works most of the time, it is basically an attempt to crawl back to the linear classpath and its JAR hell.
Hope this helps, kind regards,
Peter Kriens
On 6 mei 2010, at 22:33, Donald Whytock wrote:
> I wound up having to create a factory in bundle.b that's an extension
> of a class in bundle.a. The bundle.b subclass would override a method
> for providing an instantiation of the desired class. I had to
> instantiate the factory in bundle.b and pass it to bundle.a. That
> lets bundle.a crank out the class defined in bundle.b without the
> bundle.b class definition.
>
> Close to putting out a .jar, but there's an example of it at
>
> http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
>
> Don
>
> On Thu, May 6, 2010 at 3:28 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>> On 5/6/10 14:06, Marco หงุ่ยตระกูล-Schulze wrote:
>>>
>>> Hi Richard,
>>>
>>> thanks a lot for this quick response! Is it planned to implement buddy
>>> class loading, soon? After some more research, I stumbled over the issue
>>> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
>>> open for about 4 years already.
>>>
>>
>> I don't think so. There are issues around implementing this as a general
>> mechanism that cannot be resolved, so we've just not progressed on it.
>> Generally speaking, we end up coming up with case-by-case solutions when we
>> run into scenarios needing such capabilities.
>>
>> -> richard
>>
>>> Best regards, Marco :-)
>>>
>>>
>>> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>>>
>>>>
>>>> No, sorry, Felix doesn't support such a mechanism.
>>>>
>>>> -> richard
>>>>
>>>> On 5/6/10 13:09, Marco หงุ่ยตระกูล-Schulze wrote:
>>>>
>>>>>
>>>>> Hello *,
>>>>>
>>>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>>>> but didn't find anything. Is it maybe simply called differently?
>>>>>
>>>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>>>> a framework and my.bundle.b some implementation for it. Thus,
>>>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>>>> interfaces that are provided by the framework), but my.bundle.a would
>>>>> know nothing about my.bundle.b.
>>>>>
>>>>> There are situations (especially when integrating non-OSGi-aware systems
>>>>> into an OSGi context), when the framework in my.bundle.a wants to
>>>>> instantiate a class from my.bundle.b, but this is not possible as
>>>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>>>> ClassNotFoundException when taking the class name (that was maybe
>>>>> somehow added to a configuration by my.bundle.b) and trying a
>>>>> Class.forName(...).
>>>>>
>>>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>>>> supports it by the following entry in its MANIFEST.MF:
>>>>>
>>>>> Eclipse-BuddyPolicy: registered
>>>>>
>>>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>>>> own classes should be available to my.bundle.a by having these two
>>>>> entries in its MANIFEST.MF:
>>>>>
>>>>> Require-Bundle: my.bunde.a
>>>>> Eclipse-RegisterBuddy: my.bunde.a
>>>>>
>>>>> The important thing is that my.bundle.a still does not reference
>>>>> my.bundle.b anywhere (the framework must of course not know any of its
>>>>> implementations), but is still able to load the (exported) classes from
>>>>> my.bundle.b.
>>>>>
>>>>> Further information about buddy class loading can be found here:
>>>>>
>>>>>
>>>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>>>
>>>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>>>
>>>>> Best regards, Marco :-)
>>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Donald Whytock <dw...@gmail.com>.
I wound up having to create a factory in bundle.b that's an extension
of a class in bundle.a. The bundle.b subclass would override a method
for providing an instantiation of the desired class. I had to
instantiate the factory in bundle.b and pass it to bundle.a. That
lets bundle.a crank out the class defined in bundle.b without the
bundle.b class definition.
Close to putting out a .jar, but there's an example of it at
http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
Don
On Thu, May 6, 2010 at 3:28 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 5/6/10 14:06, Marco ˧��µ�С��-Schulze wrote:
>>
>> Hi Richard,
>>
>> thanks a lot for this quick response! Is it planned to implement buddy
>> class loading, soon? After some more research, I stumbled over the issue
>> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
>> open for about 4 years already.
>>
>
> I don't think so. There are issues around implementing this as a general
> mechanism that cannot be resolved, so we've just not progressed on it.
> Generally speaking, we end up coming up with case-by-case solutions when we
> run into scenarios needing such capabilities.
>
> -> richard
>
>> Best regards, Marco :-)
>>
>>
>> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>>
>>>
>>> No, sorry, Felix doesn't support such a mechanism.
>>>
>>> -> �richard
>>>
>>> On 5/6/10 13:09, Marco ˧��µ�С��-Schulze wrote:
>>>
>>>>
>>>> Hello *,
>>>>
>>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>>> but didn't find anything. Is it maybe simply called differently?
>>>>
>>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>>> a framework and my.bundle.b some implementation for it. Thus,
>>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>>> interfaces that are provided by the framework), but my.bundle.a would
>>>> know nothing about my.bundle.b.
>>>>
>>>> There are situations (especially when integrating non-OSGi-aware systems
>>>> into an OSGi context), when the framework in my.bundle.a wants to
>>>> instantiate a class from my.bundle.b, but this is not possible as
>>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>>> ClassNotFoundException when taking the class name (that was maybe
>>>> somehow added to a configuration by my.bundle.b) and trying a
>>>> Class.forName(...).
>>>>
>>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>>> supports it by the following entry in its MANIFEST.MF:
>>>>
>>>> Eclipse-BuddyPolicy: registered
>>>>
>>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>>> own classes should be available to my.bundle.a by having these two
>>>> entries in its MANIFEST.MF:
>>>>
>>>> Require-Bundle: my.bunde.a
>>>> Eclipse-RegisterBuddy: my.bunde.a
>>>>
>>>> The important thing is that my.bundle.a still does not reference
>>>> my.bundle.b anywhere (the framework must of course not know any of its
>>>> implementations), but is still able to load the (exported) classes from
>>>> my.bundle.b.
>>>>
>>>> Further information about buddy class loading can be found here:
>>>>
>>>>
>>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>>
>>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>>
>>>> Best regards, Marco :-)
>>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/6/10 14:06, Marco หงุ่ยตระกูล-Schulze wrote:
> Hi Richard,
>
> thanks a lot for this quick response! Is it planned to implement buddy
> class loading, soon? After some more research, I stumbled over the issue
> https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
> open for about 4 years already.
>
I don't think so. There are issues around implementing this as a general
mechanism that cannot be resolved, so we've just not progressed on it.
Generally speaking, we end up coming up with case-by-case solutions when
we run into scenarios needing such capabilities.
-> richard
> Best regards, Marco :-)
>
>
> On 05/06/2010 07:46 PM, Richard S. Hall wrote:
>
>> No, sorry, Felix doesn't support such a mechanism.
>>
>> -> richard
>>
>> On 5/6/10 13:09, Marco หงุ่ยตระกูล-Schulze wrote:
>>
>>> Hello *,
>>>
>>> I'm new to Felix but use Eclipse already for a few years. Equinox
>>> supports so-called buddy-class-loading. Does Felix have such a feature,
>>> too? If so, how is it named? I looked for "felix buddy class loading",
>>> but didn't find anything. Is it maybe simply called differently?
>>>
>>> If it is not clear to you, what I mean by "buddy class loading", imagine
>>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>>> a framework and my.bundle.b some implementation for it. Thus,
>>> my.bundle.b would define a dependency on my.bundle.a (to import the
>>> interfaces that are provided by the framework), but my.bundle.a would
>>> know nothing about my.bundle.b.
>>>
>>> There are situations (especially when integrating non-OSGi-aware systems
>>> into an OSGi context), when the framework in my.bundle.a wants to
>>> instantiate a class from my.bundle.b, but this is not possible as
>>> there's no dependency in this direction. Thus, my.bundle.a would get a
>>> ClassNotFoundException when taking the class name (that was maybe
>>> somehow added to a configuration by my.bundle.b) and trying a
>>> Class.forName(...).
>>>
>>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>>> supports it by the following entry in its MANIFEST.MF:
>>>
>>> Eclipse-BuddyPolicy: registered
>>>
>>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>>> own classes should be available to my.bundle.a by having these two
>>> entries in its MANIFEST.MF:
>>>
>>> Require-Bundle: my.bunde.a
>>> Eclipse-RegisterBuddy: my.bunde.a
>>>
>>> The important thing is that my.bundle.a still does not reference
>>> my.bundle.b anywhere (the framework must of course not know any of its
>>> implementations), but is still able to load the (exported) classes from
>>> my.bundle.b.
>>>
>>> Further information about buddy class loading can be found here:
>>>
>>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>>
>>> http://www.eclipsezone.com/articles/eclipse-vms/
>>>
>>> Best regards, Marco :-)
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Buddy class loading supported?
Posted by Marco หงุ่ยตระกูล-Schulze <Ma...@NightLabs.de>.
Hi Richard,
thanks a lot for this quick response! Is it planned to implement buddy
class loading, soon? After some more research, I stumbled over the issue
https://issues.apache.org/jira/browse/FELIX-42 which mentions it, but is
open for about 4 years already.
Best regards, Marco :-)
On 05/06/2010 07:46 PM, Richard S. Hall wrote:
> No, sorry, Felix doesn't support such a mechanism.
>
> -> richard
>
> On 5/6/10 13:09, Marco หงุ่ยตระกูล-Schulze wrote:
>> Hello *,
>>
>> I'm new to Felix but use Eclipse already for a few years. Equinox
>> supports so-called buddy-class-loading. Does Felix have such a feature,
>> too? If so, how is it named? I looked for "felix buddy class loading",
>> but didn't find anything. Is it maybe simply called differently?
>>
>> If it is not clear to you, what I mean by "buddy class loading", imagine
>> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
>> a framework and my.bundle.b some implementation for it. Thus,
>> my.bundle.b would define a dependency on my.bundle.a (to import the
>> interfaces that are provided by the framework), but my.bundle.a would
>> know nothing about my.bundle.b.
>>
>> There are situations (especially when integrating non-OSGi-aware systems
>> into an OSGi context), when the framework in my.bundle.a wants to
>> instantiate a class from my.bundle.b, but this is not possible as
>> there's no dependency in this direction. Thus, my.bundle.a would get a
>> ClassNotFoundException when taking the class name (that was maybe
>> somehow added to a configuration by my.bundle.b) and trying a
>> Class.forName(...).
>>
>> Here comes buddy-class-loading into play: my.bundle.a would say that it
>> supports it by the following entry in its MANIFEST.MF:
>>
>> Eclipse-BuddyPolicy: registered
>>
>> my.bundle.b would declare a dependency on my.bundle.b and say that its
>> own classes should be available to my.bundle.a by having these two
>> entries in its MANIFEST.MF:
>>
>> Require-Bundle: my.bunde.a
>> Eclipse-RegisterBuddy: my.bunde.a
>>
>> The important thing is that my.bundle.a still does not reference
>> my.bundle.b anywhere (the framework must of course not know any of its
>> implementations), but is still able to load the (exported) classes from
>> my.bundle.b.
>>
>> Further information about buddy class loading can be found here:
>>
>> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
>>
>> http://www.eclipsezone.com/articles/eclipse-vms/
>>
>> Best regards, Marco :-)
Re: Buddy class loading supported?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
No, sorry, Felix doesn't support such a mechanism.
-> richard
On 5/6/10 13:09, Marco หงุ่ยตระกูล-Schulze wrote:
> Hello *,
>
> I'm new to Felix but use Eclipse already for a few years. Equinox
> supports so-called buddy-class-loading. Does Felix have such a feature,
> too? If so, how is it named? I looked for "felix buddy class loading",
> but didn't find anything. Is it maybe simply called differently?
>
> If it is not clear to you, what I mean by "buddy class loading", imagine
> you have two plugins: my.bundle.a and my.bundle.b. my.bundle.a contains
> a framework and my.bundle.b some implementation for it. Thus,
> my.bundle.b would define a dependency on my.bundle.a (to import the
> interfaces that are provided by the framework), but my.bundle.a would
> know nothing about my.bundle.b.
>
> There are situations (especially when integrating non-OSGi-aware systems
> into an OSGi context), when the framework in my.bundle.a wants to
> instantiate a class from my.bundle.b, but this is not possible as
> there's no dependency in this direction. Thus, my.bundle.a would get a
> ClassNotFoundException when taking the class name (that was maybe
> somehow added to a configuration by my.bundle.b) and trying a
> Class.forName(...).
>
> Here comes buddy-class-loading into play: my.bundle.a would say that it
> supports it by the following entry in its MANIFEST.MF:
>
> Eclipse-BuddyPolicy: registered
>
> my.bundle.b would declare a dependency on my.bundle.b and say that its
> own classes should be available to my.bundle.a by having these two
> entries in its MANIFEST.MF:
>
> Require-Bundle: my.bunde.a
> Eclipse-RegisterBuddy: my.bunde.a
>
> The important thing is that my.bundle.a still does not reference
> my.bundle.b anywhere (the framework must of course not know any of its
> implementations), but is still able to load the (exported) classes from
> my.bundle.b.
>
> Further information about buddy class loading can be found here:
>
> https://www.jfire.org/modules/phpwiki/index.php/Buddy%20and%20remote%20classloading
> http://www.eclipsezone.com/articles/eclipse-vms/
>
> Best regards, Marco :-)
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org