Niclas Hedhman wrote: > > > On 11/10/06, *Makas Tzavellas* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > For the ManagedServiceFactory's case, how would it be possible for > it to > serve different instance of a service if it's not registered? > > > The ManagedServiceFactory is registered as the service. For instance; > > public class Abc implements ManagedServiceFactory { ... } > > public class Activator > { > : > public void start( BundleContext ctx ) > throws Exception > { > Abc factory = new Abc(); > reg = ctx.registerService( Def.class.getName(), factory, null ); > : > } > : > } > > So when the client is requesting the Def service, Abc is asked to > create one for the client. If the same client bundle is requesting the > same service, the factory is not involved, and stuff handled by the > framework. > Uh, are you sure about the code above? ManagedServiceFactory only have these methods public String getName(); public void updated(String pid, Dictionary properties) throws ConfigurationException; public void deleted(String pid);
Which seems to me that it's only suppose to be registered as ManagedServiceFactory.class.getName() not Def.class.getName(). I dont think ManagedServiceFactory is treated the same way as ServiceFactory. > > 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." > > > Not sure what this passage is referring to. Possibly there is a > context that I need to look at, and no time right now for that. > > 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. > > > ok. sounds like a non-factory case. All client bundles share the same > instance, hence no factory. > Client only *shares* the same instance if they have the share same configuration. Meaning, Client A and B wants to connect to database MESH, so they share the same instance, Client C wants to connect to database SMASH, which then will be using another instance of the service. > > 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 ); > > > Ok. So, if the service instance is required to be killed and > re-instantiated on configuration updates, you need an internal > mechanism in the Jdo service subsystem, so that the instance is > "killed" on updated() and re-instantiated straight away. However, that > sounds like an anti-pattern and the service should be able to throw > away any Jdo resources that need to be re-initialized and bring that > up again, without killing the OSGi service instance. > updated() also has the "side effect" that the serviceModified() method > in the tracker is called, in case clients need to know. The configuration updates are not suppose (or not required) to kill/re-instantiate the service (unless I misunderstood the spec). Upon changes in the configuration, the ManagedServiceFactory will be called, which then ManagedServiceFactory implementation will find the service instance being configured and set the new properties. E.g the url for the database connection has changed for database MESH, the implementation of ManagedServiceFactory receives an update event to change it, it looks up the service using that configuration and sets the new url. Subsequent use of the same service will be connecting to the new url database (and after closing connection to the old database). The client is not involved and doesnt have to know that the service instance has changed. > > 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. > > > AFAICT, no factory at all is needed for the JDO provider service, but > I assume there are session objects that needs to be handed out. > Will continue more later... > > 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
