aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-1425) Support both osgi.bundle and osgi.fragment resource types when given a Subsystem-Content header clause with an unspecified type attribute.
Date Tue, 06 Oct 2015 17:13:26 GMT

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

John Ross commented on ARIES-1425:
----------------------------------

A few implementation notes.

The integrity of equals/hashCode will not be violated. That is, Subsystem-Content header values
"foo" and "foo;type=osgi.bundle" will be equal as before.

The Deployed-Content header in the generated deployment manifest will reflect the type that
was selected.

The Subsystem-Content header in both the generated subsystem manifest as well as in getSubsystemHeaders
will reflect whether or not the type attribute was originally specified. That is, the default
value will not be added if not already present. This will help explain how a fragment was
provisioned instead of a bundle for the value "foo". This will never happen for the value
"foo;type=osgi.bundle".

 



> Support both osgi.bundle and osgi.fragment resource types when given a Subsystem-Content
header clause with an unspecified type attribute.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-1425
>                 URL: https://issues.apache.org/jira/browse/ARIES-1425
>             Project: Aries
>          Issue Type: Task
>          Components: Subsystem
>    Affects Versions: subsystem-2.0.4
>            Reporter: John Ross
>            Assignee: John Ross
>             Fix For: subsystem-2.0.6
>
>
> Before ARIES-1368, the Subsystems implementation would not distinguish between bundle
and fragment content. This created the following issues as discussed in that bug:
> (1) Content would not be found when the Subsystem-Content header was computed by the
implementation and fragments were provided by a remote repository.
> (2) Content would not be found when the Subsystem-Content header was specified and contained
a resource with type osgi.fragment provided by the local repository.
> However, it did not cause issues when, for example, fragment content was included as
part of the header without specifying the type, and the fragment also existed within the local
repository. 
> Unfortunately, the bug lived long enough to become an issue for consumers with a zero
migration policy. Consequently, we would like to introduce the following implementation specific
behavior without violating the specification.
> REQUIREMENTS
> (1) An unspecified type attribute in a Subsystem-Content header clause MAY indicate either
a bundle (i.e. osgi.bundle) or a fragment (i.e. osgi.fragment).
> (2) When the type attribute is not specified, the implementation MUST search for both
bundles and fragments according to the rules for discovering content resources in section
134.5.5 of the specification.
> (3) Bundles MUST be preferred over fragments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message