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-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to