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