You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Chris Channing (Commented) (JIRA)" <ji...@apache.org> on 2011/11/03 20:25:32 UTC

[jira] [Commented] (ARIES-773) Usage of a Configuration Admin service within an isolated application framework

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

Chris Channing commented on ARIES-773:
--------------------------------------

I have created the patch and documented the solution (including what I've changed/added and why). I have verified locally that all of the unit/itests are passing (double checked using a vanilla trunk and then applied the patch).
                
> 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