[ 
https://issues.apache.org/jira/browse/ARIES-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501255#comment-13501255
 ] 

Amardeep Bhattal commented on ARIES-929:
----------------------------------------

In response to Tom ...

Yes we're basically handing an IDirectory over to be installed, rather than a 
URL of a file that may be opened as a ZipInputStream (which is then turned into 
an IDirectory object). We can spec the URL to include values for symbolic name 
and version if required, I'd hope to have those done in exactly the same way as 
for subsystem scheme URLs. I do agree that having a protocol handler for such a 
scheme is a potentially nice approach as it removes the need for the 
IDirectoryFinder interface in Apache Aries, but we don't really want to take 
"loose" content from an IDE, gather it up, and compress it so we can present a 
ZipInputStream. If it's possible to implement a ZipInputStream that delivers 
uncompressed content, then this may be a more viable route - perhaps a bit more 
elegant externally, but probably more complex to implement. Ultimately it 
seemed the simplest thing to do given we can easily represent our installation 
data as an IDirectory (regardless of where the actual files are), and given the 
install code just opens the URL to generate an IDirectory, was to hand the 
IDirectory over directly, so that's the route we took.

In response to John ...

Yes the code was committed by Mark, so in that respect this item is complete. 
If you are happy to add an "install(IDirectory)" method to an interface, that 
would be the simplest approach of all, but we'd assumed that wasn't feasible as 
the OSGi spec for the Subsystem interface does not include such a method. If 
you're happy to add one anyway, or to add one on a sub-interface, that could be 
a good (and straightforward) way to go. I'd be happy with that.
                
> 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

Reply via email to