I have a SOAP service (AXIS implementation) running inside Tomcat 5.0. This service makes frequent use of an xsl transformation. I want to create an application-wide resource that will perform the transformations without needing to load the xsl file more than once. I defined a transformer factory that loads the xsl file and creates a tranformer. The transformer object is available via JNDI lookup - actually the factory is what is found, but it returns an instance of the transformer. This method works very well except for one thing - the path to the xsl file is not easily determined. I need to find a single way to find the file (something that will work independent of the os - os X on the mac results in a different path when compared to windows 2K3). The configuration file that points to my application ($CATALINA_HOME/conf/Catalina/localhost/app.xml) contains an attribute that points to the docBase. I can define the file path relative to this location in the web.xml file; BUT I cannot programmatically determine the value of the docBase attribute!!!<br> I cannot use because the application may not be under this directory. Any help will be very much appreciated.
There's javax.servlet.http.HttpServletRequest.getRealPath("/"); This allows you to find the 'real path' of the root of your webapp, but only upon a client request. You seem to need it for the factory, which is independant and globally available?
could this path be a configuration parameter of your customer factory?
ie: this path would need to be set by whoever is responsible for deploying your app, much like you need to supply parameters to configure a datasource. [ October 23, 2004: Message edited by: Mike Curwen ]
Joined: Oct 22, 2004
Thanks for the advice. I ended up specifying the path as an Environment parameter under the Context element in the App.xml file. The problem with trying to pass it in as a parameter is that the factory constructor is called separately from the 'getObjectInstance' method (invoked on a lookup) - this method has parameters passed to it. The key issue here has to do with production/development support; I did not want to have to modify code between these two environments. However, since the path is now specified in a file that is NOT part of the .war file, all is OK. David.