Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C8C6CDC7F for ; Fri, 28 Sep 2012 14:49:07 +0000 (UTC) Received: (qmail 506 invoked by uid 500); 28 Sep 2012 14:49:07 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 439 invoked by uid 500); 28 Sep 2012 14:49:07 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 431 invoked by uid 99); 28 Sep 2012 14:49:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Sep 2012 14:49:07 +0000 Date: Sat, 29 Sep 2012 01:49:07 +1100 (NCT) From: "Amardeep Bhattal (JIRA)" To: dev@aries.apache.org Message-ID: <1020689940.139455.1348843747665.JavaMail.jiratomcat@arcas> In-Reply-To: <1241571019.139443.1348843627581.JavaMail.jiratomcat@arcas> Subject: [jira] [Updated] (ARIES-929) install subsystems from IDirectory objects MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ARIES-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amardeep Bhattal updated ARIES-929: ----------------------------------- Description: 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. was: 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 url 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, and then installs 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. > 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 > Fix For: 0.4 > > 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