[
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)
