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 <[email protected]>: > 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]
