Re: [virgo-dev] Support for ConfigAdmin factory configuration in plans

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

Ok.  One final question before I go off and do this:

In BaseRepository implementation of get() API, there is a call to utility to select highest version of the artifact.

This utility is in internal package.  Although properties are not "really" versioned for now, wouldn't it be better to have something like that 

available on the Query interface?  Possibly with Predicate type of an interface?

// This is what we have now:

    public final RepositoryAwareArtifactDescriptor get(String type, String name, VersionRange versionRange) {

        Set<RepositoryAwareArtifactDescriptor> artifacts = createQuery(ArtifactDescriptor.TYPE, type).addFilter(ArtifactDescriptor.NAME, name).run();

        return RepositoryUtils.selectHighestVersionInRange(artifacts, versionRange);

    }

// Maybe this would be better long term?

createQuery(ArtifactDescriptor.TYPE, type).addFilter(ArtifactDescriptor.NAME, name).addPredicate(Predicates.selectHighestVersionInRange());

Thanks

Dmitry

On Tue, Mar 8, 2011 at 4:25 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:

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

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev