From dev-return-8323-apmail-aries-dev-archive=aries.apache.org@aries.apache.org Thu Nov 3 19:21:56 2011 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 7D820731E for ; Thu, 3 Nov 2011 19:21:56 +0000 (UTC) Received: (qmail 12523 invoked by uid 500); 3 Nov 2011 19:21:56 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 12480 invoked by uid 500); 3 Nov 2011 19:21:56 -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 12472 invoked by uid 99); 3 Nov 2011 19:21:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 19:21:56 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 19:21:53 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 99053330239 for ; Thu, 3 Nov 2011 19:21:32 +0000 (UTC) Date: Thu, 3 Nov 2011 19:21:32 +0000 (UTC) From: "Chris Channing (Updated) (JIRA)" To: dev@aries.apache.org Message-ID: <685749568.57011.1320348092628.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1982366162.56996.1320347853170.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (ARIES-773) Usage of a Configuration Admin service within an isolated application framework MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/ARIES-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Channing updated ARIES-773: --------------------------------- Attachment: patch.diff changelist Apache Aries Contribution.pdf Attachments include: The patch file Document describing the problem and my solution The SVN change list > Usage of a Configuration Admin service within an isolated application framework > ------------------------------------------------------------------------------- > > Key: ARIES-773 > URL: https://issues.apache.org/jira/browse/ARIES-773 > Project: Aries > Issue Type: New Feature > Components: Application, Blueprint > Affects Versions: 0.3, 0.4 > Environment: All > Reporter: Chris Channing > Labels: patch > Attachments: Apache Aries Contribution.pdf, changelist, patch.diff > > Original Estimate: 168h > Remaining Estimate: 168h > > Problem Summary: > Currently there is no consistent way for consuming a Configuration Admin service from an isolated application framework. The following content summarises the problems a developer would face with Aries if the Configuration Admin service is essential to their application: > - Blueprint > The isolation boundaries are slightly marred by the current Aries Blueprint CM implementation. The underlying CM namespace handler that is registered by Blueprint is wired with a Configuration Admin service that resides in the root framework. The Configuration Admin service is then subsequently used for any Blueprint bundles requiring configuration (including bundles from an isolated framework). > The compendium specification stipulates that when a Blueprint bundle is being installed/updated the Blueprint container should delegate service registrations through the Blueprint bundle context. From a configuration perspective, if the bundle that is being managed resides in an isolated framework then this creates a service visibility problem (the bundle context will reference the isolated service registry). > Consider as an example the runtime usage of a Property-Placeholder for an isolated Blueprint bundle. Within the Blueprint CM container mechanics, the Configuration Admin service (provided by the CM namespace handler) will be used to fetch an existing configuration for the supplied PID, a Managed Service will then be exposed (bound to the PID) as a hook for further configuration updates. If any configuration updates should occur for the PID the associated Managed Service exposed in the isolated application framework will never be "seen" by the Configuration Admin service in the root framework for it to notify. > - Manual > Much like the Blueprint issue mentioned above, if a bundle within an isolated application framework requires the use of the existing Configuration Admin service and needs to expose a Managed Service for future updates there is currently no way to do this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira