[jboss-osgi-issues] [JBoss JIRA] (JBOSGI-698) Provide access to OSGiMetaData for server, web, etc

Thomas Diesler (JIRA) jira-events at lists.jboss.org
Fri Jul 5 03:17:24 EDT 2013


     [ https://issues.jboss.org/browse/JBOSGI-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated JBOSGI-698:
----------------------------------

    Component/s: WildFly

    
> 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
>          Components: WildFly
>            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


More information about the jboss-osgi-issues mailing list