[
https://issues.jboss.org/browse/JBOSGI-698?page=com.atlassian.jira.plugin...
]
Thomas Diesler moved WFLY-1104 to JBOSGI-698:
---------------------------------------------
Project: JBoss OSGi (was: WildFly)
Key: JBOSGI-698 (was: WFLY-1104)
Workflow: jira (was: GIT Pull Request workflow )
Component/s: (was: OSGi)
(was: Server)
Provide access to OSGiMetaData for server, web, etc
---------------------------------------------------
Key: JBOSGI-698
URL:
https://issues.jboss.org/browse/JBOSGI-698
Project: JBoss OSGi
Issue Type: Feature Request
Reporter: Thomas Diesler
Currently we have a policy that server does not have a dependency on OSGi API and as a
result to OSGiMetaData.
In several places we do a check like this
{code}
if (depUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
...
}
{code}
This however implies that the Manifest is the only possible source of valid OSGi
metadata. The OSGi webapp spec allows for metadata to be specified as part of a
"webbundle://" URI (see AS7-6006)
To make this work, the integration code currently generates a Manifest and later
OSGiMetaData from it. The above code still works even if the deployment content does not
have a Manifest.
I propose to move the OSGiMetaData one level down so that
{code}
if (depUnit.hasAttachment(Attachments.OSGI_METADATA)) {
...
}
{code}
is the deciding criteria. As a additional benefit web would no longer need to
produce/consume the raw Manifest headers and OSGi metadata would be treated like all other
metadata structures.
--
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