[JBoss JIRA] (JBOSGI-696) Complete support for OSGi webapp
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-696?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-696:
----------------------------------
Component/s: WebApp
WildFly
> Complete support for OSGi webapp
> --------------------------------
>
> Key: JBOSGI-696
> URL: https://issues.jboss.org/browse/JBOSGI-696
> Project: JBoss OSGi
> Issue Type: Feature Request
> Components: WebApp, WildFly
> Reporter: Thomas Diesler
> Labels: roadmap
> Attachments: webapp-1.0.pdf
>
>
> Following initial support for WAB please review the spec and implement missing functionality.
> h5. 128.3.1 WAB Definition
> The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment.
> h5. 128.3.2 Starting the Web Application Bundle
> The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy.
> Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application.
> h5. 128.3.4 Publishing the Servlet Context
> The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB.
> h5. 128.3.5 Static Content
> For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes:
> WEB-INF/
> OSGI-INF/
> META-INF/
> OSGI-OPT/
> h5. 128.3.8 Stopping the Web Application Bundle
> It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id.
> h5. 128.5 Events
> * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application.
> * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path.
> * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped.
> * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests.
> * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired.
> h5. 128.6.1 Bundle Context Access
> A Servlet can obtain a Bundle Context as follows:
> {code}
> BundleContext ctxt = (BundleContext)
> servletContext.getAttribute(osgi-bundlecontext);
> {code}
> h5. 128.6.3 Resource Lookup
> The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments.
> The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute.
> h5. 128.6.5 JavaServer Pages Support
> The Web Runtime can construct a special class loader to load generated JSP
> classes such that classes from the bundle class path are visible to newly compiled JSP classes.
> This issue is complete when the TCK passes
--
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
12 years, 9 months
[JBoss JIRA] (JBOSGI-698) Provide access to OSGiMetaData for server, web, etc
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-698?page=com.atlassian.jira.plugin... ]
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
12 years, 9 months
[JBoss JIRA] (JBOSGI-696) Complete support for OSGi webapp
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-696?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-696:
----------------------------------
Comment: was deleted
(was: Won't Fix - OSGi is going to get removed)
> Complete support for OSGi webapp
> --------------------------------
>
> Key: JBOSGI-696
> URL: https://issues.jboss.org/browse/JBOSGI-696
> Project: JBoss OSGi
> Issue Type: Feature Request
> Components: WebApp, WildFly
> Reporter: Thomas Diesler
> Labels: roadmap
> Attachments: webapp-1.0.pdf
>
>
> Following initial support for WAB please review the spec and implement missing functionality.
> h5. 128.3.1 WAB Definition
> The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment.
> h5. 128.3.2 Starting the Web Application Bundle
> The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy.
> Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application.
> h5. 128.3.4 Publishing the Servlet Context
> The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB.
> h5. 128.3.5 Static Content
> For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes:
> WEB-INF/
> OSGI-INF/
> META-INF/
> OSGI-OPT/
> h5. 128.3.8 Stopping the Web Application Bundle
> It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id.
> h5. 128.5 Events
> * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application.
> * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path.
> * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped.
> * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests.
> * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired.
> h5. 128.6.1 Bundle Context Access
> A Servlet can obtain a Bundle Context as follows:
> {code}
> BundleContext ctxt = (BundleContext)
> servletContext.getAttribute(osgi-bundlecontext);
> {code}
> h5. 128.6.3 Resource Lookup
> The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments.
> The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute.
> h5. 128.6.5 JavaServer Pages Support
> The Web Runtime can construct a special class loader to load generated JSP
> classes such that classes from the bundle class path are visible to newly compiled JSP classes.
> This issue is complete when the TCK passes
--
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
12 years, 9 months
[JBoss JIRA] (JBOSGI-698) Provide access to OSGiMetaData for server, web, etc
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-698?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-698:
----------------------------------
Comment: was deleted
(was: Won't Fix - OSGi is going to get removed)
> 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
12 years, 9 months
[JBoss JIRA] (JBOSGI-696) Complete support for OSGi webapp
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-696?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-696:
----------------------------------
Summary: Complete support for OSGi webapp (was: Complete support for OSGi webapps in JBossWeb)
> Complete support for OSGi webapp
> --------------------------------
>
> Key: JBOSGI-696
> URL: https://issues.jboss.org/browse/JBOSGI-696
> Project: JBoss OSGi
> Issue Type: Feature Request
> Reporter: Thomas Diesler
> Labels: roadmap
> Attachments: webapp-1.0.pdf
>
>
> Following initial support for WAB please review the spec and implement missing functionality.
> h5. 128.3.1 WAB Definition
> The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment.
> h5. 128.3.2 Starting the Web Application Bundle
> The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy.
> Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application.
> h5. 128.3.4 Publishing the Servlet Context
> The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB.
> h5. 128.3.5 Static Content
> For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes:
> WEB-INF/
> OSGI-INF/
> META-INF/
> OSGI-OPT/
> h5. 128.3.8 Stopping the Web Application Bundle
> It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id.
> h5. 128.5 Events
> * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application.
> * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path.
> * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped.
> * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests.
> * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired.
> h5. 128.6.1 Bundle Context Access
> A Servlet can obtain a Bundle Context as follows:
> {code}
> BundleContext ctxt = (BundleContext)
> servletContext.getAttribute(osgi-bundlecontext);
> {code}
> h5. 128.6.3 Resource Lookup
> The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments.
> The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute.
> h5. 128.6.5 JavaServer Pages Support
> The Web Runtime can construct a special class loader to load generated JSP
> classes such that classes from the bundle class path are visible to newly compiled JSP classes.
> This issue is complete when the TCK passes
--
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
12 years, 9 months
[JBoss JIRA] (JBOSGI-691) Optimize OSGi subsystem bootstrap
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-691?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-691:
----------------------------------
Component/s: WildFly
> Optimize OSGi subsystem bootstrap
> ---------------------------------
>
> Key: JBOSGI-691
> URL: https://issues.jboss.org/browse/JBOSGI-691
> Project: JBoss OSGi
> Issue Type: Feature Request
> Components: WildFly
> Reporter: Thomas Diesler
>
> The OSGi subsystem in AS7 is alrady activated lazily. However, in many cases users only want to deploy a simple artefact that "happens to be" an OSGi bundle (i.e. a JDBC driver) and do not want to deploy a large set of interconnected bundles that make up a complex modular enterprise application. For those cases the OSGi subsystem should bootstrap in a jiffy and we should not see a performance impact that is worth talking about.
--
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
12 years, 9 months