Niclas Hedhman wrote: > > > On 11/10/06, *Makas Tzavellas* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > My question is for each of the service objects created by > ServiceFactory, how can their separate configuration be managed > through > ManagedServiceFactory or are they suppose to be configured through > ManagedService? > > > The configuration is determined through the PID. And the PID is > associated with the service registration, which for > ManagedServiceFactory is the factory itself and not the service. > Hence, the configuration is sent to the factory, and how it deals with > the service instances is its own business. > > After reading the spec on ManagedServiceFactory, my feeling is that if > we use it, we dont use ServiceFactory to create services but > ManagedServiceFactory will create services and registers them instead, > since the lifecycle of managing the services seems to be part of the > ManagedServiceFactory interface. > > > Almost, the ServiceFactory does not "register" the service. The first > time each bundle requests a service, the ServiceFactory will be asked > to serve one. For each following getService, the framework will hand > out the same service instance, without asking the factory. The > framework will also keep the count for unget() and upon the last > reference to the service instance is released then the service factory > will be notified. > Note that a getService from EACH bundle will result in a call to the > ServiceFactory, which allows the factory to serve separate instances > to each client bundle. > > So say for instance, I want to create different service instance of > JdoService, each configured to connect into different databases. > What's > the right way of doing this? Use ServiceFactory or > ManagedServiceFactory > (which then will be created via ConfigurationAdmin.createFactory() > method)? My own understanding seems to lead me to using > ManagedServiceFactory instead of ServiceFactory. > > > Probably not. ServiceFactory and ManagedServiceFactory is all about > serving different instance to different bundles, and not about > registration of many similar services with different configurations. > For the ManagedServiceFactory's case, how would it be possible for it to serve different instance of a service if it's not registered? A paragraph taken from the spec "The Managed Service Factory should then create any artifacts associated with that factory. Using the PID given in the Configuration object, the bundle may register new services (other than a Managed Service) with the Framework, but this is not required. This may be necessary when the PID is useful in contexts other than the Configuration Admin service."
> For many similar services (singleton capable) one should register each > as a normal service, probably a ManagedService so configuration can be > changed. > If the service consumer has some "say" in the configuration of the > service, then that is something that the service need to specify > itself how to deal with. That could be, for instance, a classic > service factory ( i.e. not a OSGi ServiceFactory) which defines a > create() method with some arguments. > What I'm thinking is that a JdoService instance with the same configuration should not be re-instantiated and only created for new configurations, and the configuration should be changable on runtime by a "management console (using ConfigurationAdmin)" should say the user name/password has changed without the consumer of the service needing to worry about it. Therefore the consumer of the service only need to track the required service with the right filters (assuming someone else created the configuration). E.g String filter = "(database.type=mesh)" ServiceTracker tracker = new ServiceTracker( JdoService.class.getName(), filter, this ); So question is, is ManagedServiceFactory suitable for it and is my way of using it correct? I would like to use as much standard OSGi interface as I can without resorting to own factories if that can be avoided. > > Cheers > Niclas > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
