Why not:
@Component(immediate=true,configurationPolicy=ConfigurationPolicy.require)
public class Whatever {
ServiceRegistration reg;
@Activate
protected void activate( BundleContext ctx, Dictionary<String,Object>
props) {
Certificate certificate = null;
String type = (String) props.get("type");
if ( "X509".equals(type)) {
certificate = createX509(props);
}
if ( certificate != null )
reg =
ctx.registerService(Certificate.class.getName(),certificate,props);
}
private Certificate createX509(Dictionary<String, Object> props) {
// TODO Auto-generated method stub
return null;
}
@Deactivate
protected void deactivate() {
if ( reg != null)
reg.unregister();
}
}
I do not think it would be a good idea to add this to DS. XML is a lousy
programming language and we should be careful to not move logic into XML. This
kind of stuff is a lot easier to do with Java code. If you think this is too
much code, just create a base class and extend it. The ONLY reason DS uses XML
is that it we wanted lazy behavior. We wanted to "know" about components and
their dependencies without creating a class loader. By making this info
declarative in XML we could cache it and not have to touch the bundle until it
was really needed.
Kind regards,
Peter Kriens
On 19 nov 2010, at 10:04, Martin Ždila wrote:
> Hello
>
> We are using Managed Service Factory in Declarative Services to create one
> component for every configuration. This works perfectly if the component we
> want to register is exactly of the class specified in the <implementation
> class="..."/>.
> But sometimes we need a factory to create the component of different
> implementation type. For example we want to register componend that is of
> the java.security.cert.Certificate subtype according to the configuration
> properties like:
> - certificate type (eg. X509) (this defines the real type)
> - certificate (in PEM format)
> - security provider name
>
> There may be multiple certificates registered - every with the different
> properties. We can't do <implementation
> class="java.security.cert.Certificate"/>
> because this class can't configure itself from the properties. Also the real
> implementation can be sun.security.x509.X509CertImpl or different class
> according to the "certificate type" configuration property.
>
> We checked the usage of Component Factory (factory="...") and Service
> Factory (servicefactory="...") but none seems to solve our problem. One
> solution is to use delegator design pattern, but it is too cumbersome. Is
> there some transparent way to achieve our needs using Declarative Services
> so that consumer component will only use <reference
> interface="java.security.cert.Certificate" bind="setCertificate"
> target="..."/> ?
>
> Thanks in advance
> Best regards
> --
> Ing. Martin Ždila
> tel:+421-908-363-848
> mailto:[email protected]
> http://www.zdila.sk/
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
