Hi!, Further to my previous messages, I continue with the effort of migrating our app to an uniform OSGi/DS-centric system. The last 'bastion' is our GWT web interface which -being a GWT app- has a WAR-centric format. I successfully refactored all servlets out from the war and converted into declarative OSGi services (<provide interface="javax.servlet.Servlet"/>). That way I got rid of all the messy ServiceTracker code. To further replicated the other WAR functionality to register a filter, serve static content and welcome page using the info on [1] (thanks to Achim for that link).
Now, I'm having issues with PAX-WEB and the way GWT tries to load its resources: While loading the serialization descriptors, GWT loads a local resource using the HTTP context. In my case it tries to resolve resources like this: /ctx/ctx/62394587E47773FB1594FF.gwt.rpc This resource is created by the GWT compiler and placed under : <bundle>/war/ctx/ctx/resource... Before, using the standard wab mapping (Webapp-Context: /ctx, Webapp-Root: /war) gwt would find its resources correctly. Now that I'm using the programmatic resource mapping: DefaultResourceMapping resourceMapping = new DefaultResourceMapping(); resourceMapping.setAlias( "/ctx" ); resourceMapping.setPath( "/war" ); GWT fails to load the resouce and produces the following error: 2012-06-20 12:46:36.283:INFO:/:AbcProxy: ERROR: The serialization policy file '/ctx/ctx/600000000000000773FB1594FF.gwt.rpc' was not found; did you forget to include it in this deployment? 2012-06-20 12:46:36.283:INFO:/:AbcProxy: WARNING: Failed to get the SerializationPolicy '600000000000000773FB1594FF' for module ' https://localhost:8443/ctx/ctx/'; a legacy, 1.3.3 compatible, serialization policy will be used. You may experience SerializationExceptions as a result. [N.B. The last sentence should read "you will experience a hell of serialization issues as a result"] I've tracked the issue to the HttpServiceContext loading the resource and intrepreting the path as a file and not as a relative url: getting resource: [/mx/mx/6ECAD5B3A6F908CE17E47773FB1594FF.gwt.rpc] HttpServiceContext | not a URL or invalid URL: [/ctx/ctx/600000000000000773FB1594FF.gwt.rpc], treating as a file path DefaultHttpContext | Searching bundle [bundle] for resource [/ctx/ctx/600000000000000773FB1594FF.gwt.rpc] This obviously fails, as this resource is located under /war/ctx/ctx/ in bundle file system. This seems to relate to bug PAXWEB-314 [2] which implementation is to turn the relative path into a file path: // IMPROVEMENT start PAXWEB-314 257 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#257> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> try { 258 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#258> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> resource = new URL <http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/net/URL.java#URL>(path); 259 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#259> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> LOG <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java#HttpServiceContext.0LOG>.debug <http://grepcode.com/file/repo1.maven.org/maven2/org.slf4j/slf4j-api/1.6.1/org/slf4j/Logger.java#Logger.debug%28java.lang.String%29>( "resource: [" + path + "] is already a URL, returning" ); 260 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#260> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> return resource; 261 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#261> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> } 262 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#262> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> catch (MalformedURLException <http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/net/MalformedURLException.java#MalformedURLException> e) { 263 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#263> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> // do nothing, simply log 264 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#264> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> LOG <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java#HttpServiceContext.0LOG>.debug <http://grepcode.com/file/repo1.maven.org/maven2/org.slf4j/slf4j-api/1.6.1/org/slf4j/Logger.java#Logger.debug%28java.lang.String%29>( "not a URL or invalid URL: [" + path + "], treating as a file path" ); 265 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#265> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> } 266 <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#266> <http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.web/pax-web-jetty/1.1.2/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java?av=h#> // IMPROVEMENT end PAXWEB-314 Is there a way to work around this issue? Is somebody using GWT and PAX-WEB using OSGi services instead of a WAB? One possible way is to copy the /war/ctx produced by the GWT compiler back to /ctx, but I'd like to find a decent solution before going into the hack direction. Any pointers? -kr, Gerard. [1] - https://github.com/ops4j/org.ops4j.pax.web/blob/master/samples/whiteboard/src/main/java/org/ops4j/pax/web/extender/samples/whiteboard/internal/Activator.java [2] - http://team.ops4j.org/browse/PAXWEB-314
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
