Hi, I have no knowledge that someone tried to put BIRT on Pax Web. Sorry :)
Regarding your issues: 1. context.getRealPath( path ) As you can see bellow I guess BIRT guys did not check enough the servlet specs or is maybe a prerequisite that BIRT war must run exploded (which I doubt). I guess that in context of OSGi my suppositions from Pax Web are correct. Here are the servlet specs (2.5) about the subject: Section: SRV.3.5 Path Translation Methods ... In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Section: SRV.15.2.8 ServletContext ... getRealPath(String) public java.lang.String getRealPath(java.lang.String path) Returns a String containing the real path for a given virtual path. For example, the path "/index.html" returns the absolute file path on the server's file-system would be served by a request for "http://host/contextPath/index.html";, where contextPath is the context path of this ServletContext. The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive). Parameters: path - a String specifying a virtual path Returns: a String specifying the real path, or null if the translation cannot be performed 2. context.getResource( "/" ) I checked the HttpService specs and there is no clear specification about what should be done in such a case. So, then as 102.11.2.5 says that to support servlet context get resource http context should delegate to bundle getResource I would say that the bundle specs about this should lead == in the case of requesting "/" it should return the root of the bundle. So, this is a bug in current Pax Web implementation. Brett, please create an issue in jira and I will solve it asap, or you can solve that (http://issues.ops4j.org/jira/browse/PAXWEB) Alin On Wed, Feb 27, 2008 at 7:18 PM, Brett Wooldridge <[EMAIL PROTECTED]> wrote: > > Hey guys, > > I am trying to get the BIRT war file deploying under Pax web (using the > extender-war bundle) and am running into some issues maybe some expert > advice can cure. > > When the war is deploying, I am getting a NullPointerException in BIRT > initialization. It appears that the BIRT code, in a class called > ParameterAccessor is calling this ServletContext method: > > context.getRealPath( path ); > > It appears that this gets routed to HttpServiceContext.SContext which does > not override the default behavior and instead returns null. I believe it > should get a value here. That is the first issue. Subsequently, because it > is returned a null from context.getRealPath() it calls context.getResource() > in this case with a value of "/" ... i.e. Context.getResource("/"). The > implementation of this in Pax is WebAppHttpContext, which calls the Path > class to normalize the path. The logic from path is this: > > public static String normalizeResourcePath( final String path ) > { > if( path == null ) > { > return null; > } > String normalizedPath = replaceSlashes( path ); > if( normalizedPath.startsWith( "/" ) ) > { > normalizedPath = normalizedPath.substring( 1 ); > } > return normalizedPath; > } > > Because the path is simply "/" the logic here results in an empty path > name, which is then supplied to the bundle as the resource to load. The > messages from my log are: > > [HttpServiceContext ] INFO - getting resource: [/] > [WebAppHttpContext ] DEBUG - Searching bundle > [reference:file:./core/org.ziptie.server.birt_1.0.0.dev [73]] for resource > [/], normalized to [] > [WebAppHttpContext ] DEBUG - Resource not found > [HttpServiceContext ] INFO - found resource: null > > So I think there maybe two separate issues. In the first, shouldn't > HttpServiceContext.SContext also override getRealPath()? And in the second, > I think the Path.normalizeResourcePath() should not remove the leading slash > if that is all there is in the path. In fact, I think OSGi allows a leading > "/" when requesting bundle resources. Both "/tmp" and "tmp" refer to the > same directory within a bundle (i.e. "tmp" in the root of the bundle). > > Has anyone else gotten BIRT deployed under Pax? And does anyone know > whether the above analysis is correct? > > Thanks, > Brett > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
