aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <>
Subject [jira] [Commented] (ARIES-929) install subsystems from IDirectory objects
Date Thu, 11 Oct 2012 12:57:03 GMT


Thomas Watson commented on ARIES-929:

This approach seems overly complicated to achieve the goal.  If I understand it correctly
you want the ability to install an esa from some location that is not necessarily a zip archive
(a directory, a set of directories, in-memory etc).  But to do so you introduce a new schema
to the subsystem installation.  Will this idirfinder: also support the params that the subsystem:
schema supports for specifying default values for the symbolic name and version.  Can you
give some examples of what the idirfinder: URL would look like?

It seems like a much more simple thing to do would be to introduce your own protocol handler
that simply presents a ZipInputStream to the subsystems implementation when the URL steam
is opened.  For example, you could introduce a idirectory: protocol that allows you to encode
information you need to find the content (I assume that is already needed for you current
proposoal).  Then all you do is use idirectory URLs to install (for sane cases where the esa
specifies its own symbolic name and version):  

idirectory:<data for the handler to find the content>

Or embed the idirectory URL in a subsystem: URI (for the insane cases where the esa does not
specify its own symbolic name and version)


The idirectory handler can do what every you want to find the content for the esa.  It can
look up services and all that.  But it must convert the content to a ZipInputStream for the
subsystems implementation.  This is a much better abstraction in my opinion because it does
not back the IDirectory support directly into the subsystems implementation, rather it abstracts
it out into a handler and the subsystems implementation has no need to be aware of the details
of IDirectory services.

I am anticipating a concern about performance to convert random IDirectory content into a
ZipInputStream, but I really don't think install time performance is a huge concern and I
would like to see the numbers before introducing such things directly into the subsystems

> 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
>            Assignee: Mark Nuttall
>             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