[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Support for ConfigAdmin factory configuration in plans
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Tue, 8 Mar 2011 09:25:02 +0000
- Delivered-to: email@example.com
I also prefer option 1.
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" />
> (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?
> virgo-dev mailing list