aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Updated] (ARIES-956) Add ability to update the sharing policy of composite subsystems.
Date Tue, 06 Nov 2012 14:08:11 GMT


John Ross updated ARIES-956:


The attached interface contains the design proposal. 

Subsystem services will be registered under both org.osgi.service.subsystem.Subsystem and
org.apache.aries.subsystem.core.AriesSubsystem interfaces. 

Where possible (e.g., install), the interface overrides methods in order to return the AriesSubsystem
type. Note this is not possible for the methods getChildren() and getParents(), which will
continue to return type Subsystem and require casting.

The method addRequirements(Collection<org.osgi.resource.Requirement> requirements) allows
additional requirements to be added to the sharing policy post installation.

The method install(String, IDirectory) : AriesSubsystem allows a subsystem to be installed
as an IDirectory.

Notes & Issues
(1) Are there subsystem type restrictions in terms of adding requirements? For features, this
would presumably be a no-op since they import everything anyway. Definitely allowed for composites
since that's the current use case. What about applications? I've heard preferences expressed
on both sides (allowed or disallowed).

(2) Are the added requirements considered to be part of the deployment manifest?

(3) If the intent is that addRequirements be reused for added dynamic imports (RFC 191) then
the answer to the question posed in (1) must be that requirements may be added to applications,
and the answer to (2) must be no.

(4) The IDirectory currently may not be null. This differs from install(String, InputStream)
where the InputStream may be null. It didn't make sense to allow null for an IDirectory since
the whole purpose of the method was to avoid the copy and extract overhead from FileSystem.getFSRoot(InputStream).
> Add ability to update the sharing policy of composite subsystems.
> -----------------------------------------------------------------
>                 Key: ARIES-956
>                 URL:
>             Project: Aries
>          Issue Type: New Feature
>          Components: Subsystem
>            Reporter: John Ross
>            Assignee: John Ross
>         Attachments:
> I`m looking to implement a "Shared Bundle Subsystem" which is basically a subsystem container
for other subsystems. It looks like there was consideration for this scenario in the spec
as there is talk of an application container in the section which discusses appDependencies.

> I have created a subsystem of type composite to which I am attempting to install an application
subsystem. The problem is that the dependencies for the application subsystem cannot be satisfied
because the manifest of the composite does not import them. At the point that I install the
composite I can't supply the imports because I don't yet know which applications (and therefore
which dependencies) will be installed. 
> Ideally what I was hoping for was an ability to import all available packages into the
composite from the parent (in this case the root subsystem). I have attempted various methods
of achieving this , (e.g. Including an empty bundle in the composite which has a DynamicImport-Package:
*) but nothing seems to work. 
> Can you think of a way of implementing this scenario in the existing Subsystem framework?
It's a fundamental part of what we (used to) do with the old composite bundle framework code
so I`m hoping we can find a solution! 

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:

View raw message