[
https://issues.apache.org/jira/browse/ARIES-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474108#comment-13474108
]
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)
subsystem://idirectory:<...>?Subsystem-SymbolicName=lazy.dev&Subsystem-Version=1.0.0
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 implementation.
> install subsystems from IDirectory objects
> ------------------------------------------
>
> Key: ARIES-929
> URL: https://issues.apache.org/jira/browse/ARIES-929
> 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, org.apache.aries.util-r42.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: http://www.atlassian.com/software/jira
