On 11/10/06, Makas Tzavellas <[EMAIL PROTECTED]> wrote:
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.
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.
ok. sounds like a non-factory case. All client bundles share the same instance, hence no factory.
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.
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.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.
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.
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.
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.
Niclas
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
