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 <[email protected]> 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 <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
