> -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > > "Boris Brinza" <[EMAIL PROTECTED]> writes: > > >it seems turbine has problem reading stuff from war files.... > > if jboss doesn't explode the whole webapp but only libs and classes, > then me might have to rethink the way we're getting our resources > files. And the routines to compute the absolute names of the files. >
These are my finding regarding this specific topic. After testing pure .EAR and .WAR deployments with JBoss+Tomcat and Tomcat, it seems that Turbine has a problem reading the configuration files. The deployment scenarios that I tested for a typical Turbine webapp were: JBoss+Tomcat (3.0, 4.0.6) ------------------------- .EAR .WAR .WAR (with web.xml containing properties=WEB-INF/conf/TR.props instead of /WEB-INF..) .WAR manually expandend (*) Tomcat (4.1.18) --------------- .WAR (using the maven tomcat goals for cmd line deployment, remove, reload, etc., ) .WAR (with web.xml containing properties=WEB-INF/conf/TR.props instead of /WEB-INF..) .WAR (dropped into the webapps folder) (*) The items marked with (*) resulted in a succesfully running Turbine webapp, the rest always produced: (!) NOTICE: Turbine: init() failed: org.apache.turbine.services.InitializationException: Can't load file null/WEB-INF/conf/TurbineResources.properties The first solution that I found, which I haven't had the time to test it but I want to share what I found, is that we need to replace the javax.ServletContext.getRealPath() calls by javax.ServletContext.getResource() or javax.ServletContext.getResourceAsStream() as needed in org.apache.turbine.Turbine. Because the documentation that I found says: java api doc ------------ public String getRealPath(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 filesystem 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). Craig McClanahan (tomcat developer) post in tomcat mailing list: > Craig McClanahan > > PS: As a side issue, I would encourage web app developers to start using > ServletContext.getResource() and ServletContext.getResourceAsStream(), > instead of ServletContext.getRealPath() followed by file I/O, to access internal > resources. > The reason for this is that a servlet container is *not* required to run your web > app out of a filesystem (as Tomcat currently does) -- it may run them directly from a JAR > file, or in an environment like Oracle's where the web app's resources are actually BLOB > objects stored in a database, rather than being accessible as files. Comments? Rogelio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
