Hello Berin!
AT> + public void setContextDirectory( final URL url )
Further investigation has shown that this patch _is_ needed. In fact, in a servlet I do
URL urlRoot = servletContext.getResource( "/WEB-INF/avalon" ); String stringRoot = urlRoot.toExternalFort(); FortressConfig.setContextDirectory( stringRoot );
You can bind a File object directly like this:
FortressConfig.setContextDirectory(
servletContext.getRealPath( "/WEB-INF/avalon" ) );and I get something like (writing by memory) file:/C:/file/D:\goj\t331ah\webapps\tst\WEB-INF\avalon on Windows.
When however I first create a DefaultContext() and bind in urlRoot as "context-root" to it and create FortressContext on it then all is ok file:D:\goj\t331ah\webapps\tst\WEB-INF\avalon
So, I'm resending the patch.
The problem here is a bug in the toExternalForm() method. This is most likely from your J2EE servlet container vendor. Notice that there is no colon after the second file? There is also no protocol named "file/D" so that is why it fails. The thing is I believe Fortress expects a File root, although it is primarily for the SourceResolver--which can handle both URL and File.
We need to make it simple to work with--and either work with Files or URLs. The thing is that some vendors like IBM WebSphere relocate everything and use a "classloader:" protocol. If you use the context root as a relative location for the log file (as is the default case), then you need a File, and not a URL.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
