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 2012/11/02 14:37:11 UTC

[jira] [Created] (ARIES-956) Add ability to update the sharing policy of composite subsystems.

John Ross created ARIES-956:
-------------------------------

             Summary: Add ability to update the sharing policy of composite subsystems.
                 Key: ARIES-956
                 URL: https://issues.apache.org/jira/browse/ARIES-956
             Project: Aries
          Issue Type: New Feature
          Components: Subsystem
            Reporter: John Ross
            Assignee: John Ross


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: http://www.atlassian.com/software/jira

[jira] [Commented] (ARIES-956) Add ability to update the sharing policy of composite subsystems.

Posted by "John Ross (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ARIES-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492857#comment-13492857 ] 

John Ross commented on ARIES-956:
---------------------------------

I added initial support for this in http://svn.apache.org/viewvc?view=revision&revision=1406875.

The API now allows null, contrary to note (4) in my previous comment, in order to be backwards compatible with the existing idirfinder URL functionality.

Modifying the current Region Digraph will fail if it was already modified by something else after the copy was made. Synchronization is done on the BasicSubsystem class in order to avoid conflicts from other subsystems whose requirements are also being updated. This will not avoid conflicts from Region Digraph users outside of the subsystems implementation. It also introduces the possibility of contention. Currently, only a single attempt is made. It might be worthwhile to make this more robust by making up to a set number of attempts in case of failure. This could also remove the need for synchronization.
                
> Add ability to update the sharing policy of composite subsystems.
> -----------------------------------------------------------------
>
>                 Key: ARIES-956
>                 URL: https://issues.apache.org/jira/browse/ARIES-956
>             Project: Aries
>          Issue Type: New Feature
>          Components: Subsystem
>            Reporter: John Ross
>            Assignee: John Ross
>         Attachments: AriesSubsystem.java
>
>
> 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: http://www.atlassian.com/software/jira

[jira] [Commented] (ARIES-956) Add ability to update the sharing policy of composite subsystems.

Posted by "John Ross (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ARIES-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489439#comment-13489439 ] 

John Ross commented on ARIES-956:
---------------------------------

Further discussion regarding this issue took place outside of JIRA and the mailing lists. Assuming I understand correctly, the result of that discussion was that a requirement exists for the ability to update the sharing policy of an already installed composite. I realize this is all within the context of the broader discussion of updating subsystems in general but wanted to narrow the scope here to address the immediate issue. Is this scope sufficient?
                
> Add ability to update the sharing policy of composite subsystems.
> -----------------------------------------------------------------
>
>                 Key: ARIES-956
>                 URL: https://issues.apache.org/jira/browse/ARIES-956
>             Project: Aries
>          Issue Type: New Feature
>          Components: Subsystem
>            Reporter: John Ross
>            Assignee: John Ross
>
> 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: http://www.atlassian.com/software/jira

[jira] [Updated] (ARIES-956) Add ability to update the sharing policy of composite subsystems.

Posted by "John Ross (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ARIES-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ross updated ARIES-956:
----------------------------

    Attachment: AriesSubsystem.java

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: https://issues.apache.org/jira/browse/ARIES-956
>             Project: Aries
>          Issue Type: New Feature
>          Components: Subsystem
>            Reporter: John Ross
>            Assignee: John Ross
>         Attachments: AriesSubsystem.java
>
>
> 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: http://www.atlassian.com/software/jira

[jira] [Resolved] (ARIES-956) Add ability to update the sharing policy of composite subsystems.

Posted by "John Ross (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ARIES-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ross resolved ARIES-956.
-----------------------------

    Resolution: Fixed

Marking as fixed. Please reopen if the requested functionality is not sufficient.
                
> Add ability to update the sharing policy of composite subsystems.
> -----------------------------------------------------------------
>
>                 Key: ARIES-956
>                 URL: https://issues.apache.org/jira/browse/ARIES-956
>             Project: Aries
>          Issue Type: New Feature
>          Components: Subsystem
>            Reporter: John Ross
>            Assignee: John Ross
>         Attachments: AriesSubsystem.java
>
>
> 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: http://www.atlassian.com/software/jira