aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amardeep Bhattal (JIRA)" <>
Subject [jira] [Commented] (ARIES-929) install subsystems from IDirectory objects
Date Fri, 28 Sep 2012 16:17:07 GMT


Amardeep Bhattal commented on ARIES-929:

A brief summary of the changes in the proposed code (see attached patch files) :

    New interface that the service that returns an IDirectory must implement,
    just a single method to return an IDirectory when given a URI, plus
    documentation about the format of such URIs. The version of the
    org.apache.aries.util bundle which contains this code is bumped from 1.0.0
    to 1.0.1-SNAPSHOT.

    Modify existing ServiceTrackerCustomizer methods to also look for 
    IDirectoryFinder services and hold any such services in a list (in a similar
    manner to other services), make an unmodifiable version of his list available
    via a method (also similar to one of the existing lists).
    Used during subsystem installation, existing code handled persisted 
    subsystems (location started with subsystem://) and plain URIs. Extended
    to also treat locations that start with idirfinder:// specially, in this
    case loop over any current finder services (i.e. the list in the Activator
    class), calling each one in turn until the IDirectory is found or there are
    no more finders. Although the idirfinder URI encodes an id which identifies
    which finder service should be used for the URI under consideration and it
    is also expected a service property with the finder service id is configured
    for any active finder services (so a specific one can be selected), this 
    initial implementation just loops over any available services as the number 
    of expected services is very small (~1). This implementation may be changed 
    in the future if required.
    Pick up new version of util bundle.

    Changed util bundle listed in configuration method from version 1.0.0 to
    unversioned, so that version from pom.xml (i.e. 1.0.1-SNAPSHOT) will be used.
    Cleaned-up, removed redundant imports, removed (unversioned) util bundle
    from extraBundles method which lists bundles required for this test class, as
    SubsystemTest superclass now does this.
    Added test to install, start, uninstall hello world subsystem using an 
    IDirectory (existing method does this from file). Inner class written to 
    implement an IDirectoryFinder service that provides the hello world 
    Pick up new version of util bundle.

> install subsystems from IDirectory objects
> ------------------------------------------
>                 Key: ARIES-929
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Subsystem
>    Affects Versions: 0.4
>         Environment: n/a
>            Reporter: Amardeep Bhattal
>             Fix For: 0.4
>         Attachments: org.apache.aries.subsystem.core.patch, org.apache.aries.subsystem.itests.patch,
>   Original Estimate: 336h
>  Remaining Estimate: 336h
> Subsystems may be installed by calling Subsystem.install(String) (and also the install(String,
InputStream) method). The code treats the given location string as a URI string which can
be opened to obtain installation artifacts, unless the URI has a scheme of "subsystem" in
which case an alternative leg of code is executed to install a persisted subsystem.
> It would be useful to extend this mechanism to add a new scheme ("idirfinder") which
is also treated in special way; in this case the URI is passed to a service which can return
a corresponding IDirectory object that matches the given URI, which the install code can then
use to install a subsystem using the contents of the IDirectory. To achieve this, a modification
to the subsystem install code is required (though not extensive as IDirectory objects are
already used internally during install), and an interface for the IDirectory finder service
must be defined.
> Adding this functionality would allow installation of subsystems from a variety of sources,
including expanded archive, loose config (installation artifacts distributed across disk as
produced by IDEs), in-memory etc as the only requirement is then to provide an IDirectory
front-end to the content. The alternative of gathering the content and producing an archive
file is not desirable due to the overhead this entails, particularly when an IDE is being
used for rapid development, and small changes are being made frequently.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message