[JBoss JIRA] (WFLY-658) Complete support for OSGi webapps in JBossWeb
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-658?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-658.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Complete support for OSGi webapps in JBossWeb
> ---------------------------------------------
>
> Key: WFLY-658
> URL: https://issues.jboss.org/browse/WFLY-658
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi
> 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, 10 months
[JBoss JIRA] (WFLY-1381) OSGi: "Web-ContextPath" header is not supported to install/start WAB bundle from repository
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1381?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1381.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> OSGi: "Web-ContextPath" header is not supported to install/start WAB bundle from repository
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-1381
> URL: https://issues.jboss.org/browse/WFLY-1381
> Project: WildFly
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 8.0.0.Alpha2
> Reporter: Igor Shulika
>
> I am using the latest WildFly 8.0.0.Alpha2-SNAPSHOT server to install/start all of my OSGi bundles from Maven repository. The WAB is not starting if I am just declare capability in the standalone-osgi.xml file.
>
> Here is my capability configuration.
> <capability name="org.test.sample.webapp:my-sample-webapp:1.0" startlevel="4"/>
>
> Note: When I just simply drop my WAB file inside "deployments" directory the web application starting successfully.
--
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, 10 months
[JBoss JIRA] (WFLY-1222) Allign deployment phases with OSGi terminology
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1222?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1222.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Allign deployment phases with OSGi terminology
> ----------------------------------------------
>
> Key: WFLY-1222
> URL: https://issues.jboss.org/browse/WFLY-1222
> Project: WildFly
> Issue Type: Task
> Components: OSGi, Server
> Reporter: Thomas Diesler
>
> In OSGi we have
> * INSTALLED
> * RESOLVED
> * ACTIVE
> * UNINSTALLED
> It'd be useful to talk about modules and osgi bundles in the same jagon - i.e
> If a deployment is INSTALLED it has valid metadata
> If a deployment is RESOLVED it has Module/ClassLoader associated
> If a deployment is ACTIVE it can perform its normal operation
> If a deployment is UNINSTALLED it can be removed from the system
> The task here is mainly to rename/revisit the deployment phases
--
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, 10 months
[JBoss JIRA] (WFLY-1280) Allow OSGi services to be registered as JAX-WS endpoints
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1280?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1280.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Allow OSGi services to be registered as JAX-WS endpoints
> --------------------------------------------------------
>
> Key: WFLY-1280
> URL: https://issues.jboss.org/browse/WFLY-1280
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi, Web Services
> Reporter: Thomas Diesler
>
> It should be possible to register a WS endpoint similar to this
> {code}
> public void start(BundleContext context) {
> HelloService helloService = new HelloServiceImpl();
> Dictionary props = new Hashtable();
> props.put("service.exported.interfaces", "*");
> props.put("service.exported.configs", "org.apache.cxf.ws");
> props.put("org.apache.cxf.ws.address", "http://localhost:8090/soap");
> registration = context.registerService(HelloService.class.getName(), helloService, props);
> }
> {code}
--
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, 10 months
[JBoss JIRA] (WFLY-559) Support Bundle deploy/undeploy from management operation
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-559?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-559.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Support Bundle deploy/undeploy from management operation
> --------------------------------------------------------
>
> Key: WFLY-559
> URL: https://issues.jboss.org/browse/WFLY-559
> Project: WildFly
> Issue Type: Sub-task
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 9.0.0.CR1
>
>
> There is a requirement that a bundle can install/uninstall other bundles during start/stop. We support auto start/stop for bundle deployments and explicit start/stop as management operations.
> In both cases this would trigger a management operation (i.e. deploy/undeploy) from within the another management operation, which currently not supported.
--
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, 10 months
[JBoss JIRA] (WFLY-1504) Unusable wiring metadata for Apache-CXF
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1504?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1504.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Unusable wiring metadata for Apache-CXF
> ---------------------------------------
>
> Key: WFLY-1504
> URL: https://issues.jboss.org/browse/WFLY-1504
> Project: WildFly
> Issue Type: Bug
> Components: OSGi, Web Services
> Reporter: Thomas Diesler
>
> When integrating the [camel-cxf|http://camel.apache.org/cxf.html] component we see a number of package requirements on cxf
> {code}
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.binding.soap)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.injection)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.logging)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.util)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration.blueprint)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration.spring)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.headers)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.helpers)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.io)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.message)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.service.model)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.transport)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.ws.addressing)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.wsdl)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]]
> {code}
> most of these are contained in the org.apache.cxf.impl module, which however takes a "one bucket for all approach" that makes it impossible to use the metadata shipped with the individual cxf artefacts
> {code}
> <resources>
> <resource-root path="cxf-rt-bindings-coloc-2.7.5.jar"/>
> <resource-root path="cxf-rt-bindings-object-2.7.5.jar"/>
> <resource-root path="cxf-rt-bindings-soap-2.7.5.jar"/>
> <resource-root path="cxf-rt-bindings-xml-2.7.5.jar"/>
> <resource-root path="cxf-rt-core-2.7.5.jar"/>
> <resource-root path="cxf-rt-databinding-aegis-2.7.5.jar"/>
> <resource-root path="cxf-rt-databinding-jaxb-2.7.5.jar"/>
> <resource-root path="cxf-rt-frontend-jaxws-2.7.5.jar"/>
> <resource-root path="cxf-rt-frontend-simple-2.7.5.jar"/>
> <resource-root path="cxf-rt-management-2.7.5.jar"/>
> <resource-root path="cxf-rt-transports-http-2.7.5.jar"/>
> <resource-root path="cxf-rt-transports-jms-2.7.5.jar"/>
> <resource-root path="cxf-rt-transports-local-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-addr-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-mex-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-policy-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-rm-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-security-2.7.5.jar"/>
> <resource-root path="cxf-rt-ws-security-2.7.5-jandex.jar"/>
> <resource-root path="cxf-tools-common-2.7.5.jar"/>
> <resource-root path="cxf-tools-java2ws-2.7.5.jar"/>
> <resource-root path="cxf-tools-validator-2.7.5.jar"/>
> <resource-root path="cxf-tools-wsdlto-core-2.7.5.jar"/>
> <resource-root path="cxf-tools-wsdlto-databinding-jaxb-2.7.5.jar"/>
> <resource-root path="cxf-tools-wsdlto-frontend-jaxws-2.7.5.jar"/>
> <resource-root path="cxf-services-sts-core-2.7.5.jar"/>
> <resource-root path="cxf-services-ws-discovery-api-2.7.5.jar"/>
> <resource-root path="cxf-xjc-boolean-2.6.1.jar"/>
> <resource-root path="cxf-xjc-dv-2.6.1.jar"/>
> <resource-root path="cxf-xjc-ts-2.6.1.jar"/>
> <!-- Insert resources here -->
> </resources>
> {code}
> A possible fix would be to separate and reexport the modules that camel-cxf integrates with
--
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, 10 months