> 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.
ManagedServiceFactory sounds like a reasonable implementation strategy
for this scenario if you want to provide and manage configurations for
the JdoService externally from Java code.
As Niclas points out, if you want to register new JdoServices
on-the-fly as configurations become available then
ManagedServiceFactory is a good way to go.
I've been spending a lot of time lately with ConfigurationAdmin and
coming up with a reasonable way of providing configuration data for
bundles and services from an external source. The approach I've come
up with allows Configurations to be created for both ManagedServices
and ManagedServiceFactories via simple properties files.
To illustrate, in the system I'm working on I've developed a
DefaultConfigurationInitializer service, and the implementation of
that service that I'm currently using is a
PropertyFileConfigurationInitializer. This service implements one
method, initializeConfigurations(ConfigurationAdmin configAdmin).
This method scans a directory specified via a sys prop and looks for
all files that end with .msproperties, for ManagedServices, or
.msfproperties for ManagedServiceFactories. There is a special naming
convention that these properties files need to follow. For a
ManagedService the convention is <SERVICE_PID>.msproperties and for
ManagedServiceFactories the convention is
<SERVICE_PID>-<DISCRIMINATOR_TOKEN>.msfproperties. In the case of
ManagedServiceFactories the DISCRIMINATOR_TOKEN is discarded when the
Configuration is registered, it just serves as an easy way for
developers to distinguish the instances of the factory.
We use a ManagedServiceFactory for configuring caches, in this case we
use properties files like:
net.tucana.cache-nntpArticleCache.msfproperties
net.tucana.cache-loggedInUsersCache.msfproperties
In this case, the PropertyFileConfigurationInitializer would create
and register 2 Configurations for the 'net.tucana.cache' SERVICE_PID,
so the ManagedServiceFactory registered via:
public void start(BundleContext bundleContext) {
Dictionary props = new Hashtable();
props.put(Constants.SERVICE_PID, "net.tucana.cache");
bundleContext.registerService(ManagedServiceFactory.class.getName(),
this, props);
}
would register or update cache services in the updated method as the
Configurations from the properties files above are registered with
ConfigurationAdmin via PropertyFileConfigurationInitializer.
For example:
public void updated(String pid, Dictionary config) throws
ConfigurationException {
if (serviceAlreadyRegistered(pid)) {
// update existing registered cache service
} else {
// register a service for new cache configuration
bundleContext.registerService(
CacheService.class.getName(),
new CacheImpl(),
config
)
}
}
I can send this code out if anyone's interested.
- Ben
On 11/10/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
>
> First of all, thanks Peter, I got confused over the 'real definition' and
> how I have used it in the past, i.e. combine ServiceFactory with
> ManagedServcieFactory. That said, read below;
>
> On 11/10/06, Makas Tzavellas <[EMAIL PROTECTED]> wrote:
> > 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.
> >
>
> Sounds like a case of standard simple services;
>
> JdoProvider provider1 = new JdoProviderImpl();
> Properties props = new Properties();
> props.put( Constants.SERVICE_PID, "org.hedhman.niclas.jdo.MESH " );
> props.put( Constants.SERVICE_ID, "org.hedhman.niclas.jdo.MESH" );
> reg1 = ctx.registerService( JdoProvider.class.getName(), provider1, props );
>
> JdoProvider provider2 = new JdoProvider();
> props = new Properties();
> props.put( Constants.SERVICE_PID, "org.hedhman.niclas.jdo.SMASH " );
> props.put( Constants.SERVICE_ID, "org.hedhman.niclas.jdo.SMASH" );
> reg1 = ctx.registerService( JdoProvider.class.getName(), provider2, props );
>
>
> And the client looking up with serviceID;
>
> ServiceReference[] refs = ctx.getServiceReferences(
> JdoProvider.class.getName(),
> "("+Constants.SERVICE_ID + "=MESH)" );
>
>
> or the equivalent in the ServiceTracker.
>
>
> However, IF you want to create new JdoProvider instances on-the-fly from the
> Config Admin service, you should use the ManagedServiceFactory.
>
> When ManagedServiceFactory receives a Service PID that doesn't exist before,
> it creates a new JdoProvider. IIUIC, if the service instance that the
> factory registers is a managed service, it too will receive the
> Configuration in its updated() method. Likewise, on deleted() the MSF
> removes the service registration from the framework registry.
>
> Hope that helps
>
>
> Cheers
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
