You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "John Ross (JIRA)" <ji...@apache.org> on 2013/07/09 17:01:58 UTC
[jira] [Resolved] (ARIES-952) Break dependency of Aries Subsystems
on Aries Blueprint
[ https://issues.apache.org/jira/browse/ARIES-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Ross resolved ARIES-952.
-----------------------------
Resolution: Fixed
Subsystems does not have a dependency on aries blueprint per se. Rather, it has a dependency on the org.apache.aries.application.api bundle and an implementation of the org.apache.aries.application.modelling.ModelledResourceManager service.
Currently, the only known implementation of the ModelledResourceManager service is provided by the org.apache.aries.application.modeller bundle. It is this bundle that has a dependency on aries blueprint.
Nevertheless, to hopefully improve usability, the subsystems -> aries blueprint link was softened by making the ModelledResourceManager service dependency optional. This means subsystems will now function without the org.apache.aries.application.modeller, org.apache.aries.blueprint, and org.apache.aries.proxy bundles.
However, without a ModelledResourceManager service, the functionality will suffer from the following limitations with regard to applications.
(1) Service capabilities and requirements will not be part of the install time resolution. This means application providers will not benefit from a fail-fast installation due to missing service dependencies.
(2) Service requirements will not be part of the sharing policy. This means that any service requirements must be met from within the application itself.
Composites and features will function as usual. Ways to get around (2) from above include the following.
(a) Use a composite or feature instead.
(b) Add service requirements post-installation using the addRequirements method of the AriesSubsystem interface.
(c) Provide your own deployment manifest.
(d) Modify the application's Region through RegionDigraph.
To regain full functionality, an implementation of the org.apache.aries.application.modelling.ModelledResourceManager service must be provided. Based on the current subsystems implementation, this means, at a minimum, the getServiceElements(IDirectory) method must be implemented. However, there is no guarantee that other methods will not be used in the future.
If the solution is not satisfactory, please reopen this defect with comments explaining why and what it would take to achieve the desired outcome.
> Break dependency of Aries Subsystems on Aries Blueprint
> -------------------------------------------------------
>
> Key: ARIES-952
> URL: https://issues.apache.org/jira/browse/ARIES-952
> Project: Aries
> Issue Type: Improvement
> Components: Application, Subsystem
> Reporter: Glyn Normington
> Assignee: John Ross
>
> Aries Subsystems currently has a hard dependency on Aries Blueprint (AB).
> When running Aries Subsystems in an environment where there is already a Blueprint implementation, we end up with duplicate Blueprint extenders, which is of course a recipe for disaster.
> One such environment is the Virgo kernel. Virgo depends on Gemini Blueprint (GB) because it uses the Spring DM function provided by GB. So it's not possible to substitute AB for GB.
> So the requirement is to make it possible to run Aries Subsystems with GB. Admittedly this may involve adding some GB code to support resource modelling for Blueprint, but that should be separated from the AB implementation.
> To reproduce the problematic environment, see https://github.com/glyn/aries-subsystems-on-virgo-kernel and follow the instructions in README.md. The web admin console can then be used to observe both GB and AB extenders running in the Virgo user region. Also, the nature of the hard dependency can be observed by deleting the Aries Blueprint core bundle from the Virgo kernel's repository/usr directory and restarting Virgo - the modeller no longer resolves:
> missing constraint in bundle <org.apache.aries.application.modeller_1.0.1.SNAPSHOT>
> constraint: <Import-Package: org.apache.aries.blueprint.services; version="[1.0.0,2.0.0)">
--
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