[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Support for ConfigAdmin factory configuration in plans

I also prefer option 1.

Regards,
Glyn

On 8 Mar 2011, at 02:37, Dmitry Sklyut wrote:

> Hi All,
> 
> With the changes done in kernel recently, ConfigAdmin factory configurations are supported in following scenarios:
> 1. hot deploy from pickup folder
> 2. configurations in config location of the kernel (this change is on the origin/bug325735-manager-service-factory branch right now)
> 
> Only thing that remains now is support in plan.  Plans rely on plan creator to know exact artifact type, name, and optionally version.
> This breaks down for factory configurations, because pid (i.e. name) is computed at runtime by PropertiesBridge.  PropertiesBridge also stores the actual factoryPid as an attribute of ArtifactDescriptor.
> 
> After a bit of research, I found following API that tries to resolve ArtifactDescriptor based on ArtifactSpecification:
> org.eclipse.virgo.kernel.install.artifact.internal.StandardInstallArtifactTreeInclosure.createInstallTree(ArtifactSpecification specification, String scopeName)
> 
> This API makes an assumption that all information about a particular artifact can be expressed with type/name/version.  This assumption is expressed in the call to repository:
> RepositoryAwareArtifactDescriptor artifactDescriptor = this.repository.get(type, name, versionRange);
> 
> With current implementation of factory configuration this call will have 0 chance of finding correct ArtifactDescriptor.
> Repository also has a concept of a Query.  I hope that this Query can be used to express additional filter attributes.
> 
> (1) I think minimal impact change would be in StandardInstallArtifactTreeInclosure for type=configuration to create a query vs. calling a get on Repository.
> Query will filter on the usual set of properties, i.e. type/name/version as well as additional Attribute to specify factoryPid value.
> With this approach there is no change to the plan schema or additional processing.
> 
> (2) Some other options could be using a nested property element for artifact to provide a hint that configuration is for a factory vs. a singleton configuration:
> 
> <artifact type="configuration" name="app-properties" version="1.0.0">
>  <property name="isFactory" value="true" />
> </artifact>
> 
> (3) Finally plan schema can be made less generic with namespaces, i.e. each deployment type can provide its own namespace and have richer set of attributes/elements to describe artifact:
> 
> <config:cm factory-pid="app-properties" version="1.0.0"/>
> 
> 
> I prefer option 1.  Any thoughts/pointers around this approach?
> 
> Regards,
> Dmitry
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev