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
