Hi Jan, Can you test this and report? If it works i will build it into the current version!
Regards, Henner > -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von [EMAIL PROTECTED] > Gesendet: Donnerstag, 30. Oktober 2003 07:45 > An: Jan-Friedrich Mutter; [EMAIL PROTECTED] > Betreff: Re: [dbforms] log4j on Weblogic > > > Hi Jan, > > > Hi, > > > > I have two applications running on a Bea Weblogic. The > first one is a > > dbforms 1.1.3 application, the second one uses just some > servlets. I > > have to deploy the dbforms-app in a war. Thus it is not > possible to > > use the "log4j.configuration" parameter in the web.xml because the > > ConfigServlet.initLogging() method fails trying to get the right > > configURL > > (getServletContext().getRealPath("/") returns null in a war). > > Argh ! Never had this problem. Anyway, googling on the net, I > discovered a mail that spoke about a similar problem. Here's > a solution from a nice coder: > http://www.tek-tips.com/gviewthread.cfm/lev2/3/lev3/13/pid/830 > /qid/516022 > > ---- > [...] > In the servlet v used the following to find the root of the > application. After finding the root of application, v used > the value to access a file stored in that path. Like > > String appPath = getServletContext().getRealPath("/"); > FileInputStream fis = new FileInputStream(appPath + > "/WEB-INF/config/appConfig.cfg"); > > This getRealPath() method works fine if v use the exploded > directory format. But it throws Null when v use the .war file > to deploy. > > To avoid this problem, don't use getRealPath method, if u r > using .war format for deployment. > > Instead, use getResourceAsStream() method of ServletContext > to convert the file to Stream. (i.e) use something like this. > > InputStream fis = > getServletContext().getResourceAsStream("/WEB-INF/config/appCo > nfig.cfg"); > > ---- > > So: > > InputStream fis = > getServletContext().getResourceAsStream("/WEB-INF/config/appCo > nfig.cfg"); > > should solve the problem. > > Further, there's a cool tutorial on Javaworld about "smartly > load your properties": > http://www.javaworld.com/javaworld/javaqa/2003-08/01-qa-0808-p > roperty.html > > There's the source for a "PropertyLoader" class that could > use different methods to load properties files: > > ---- > Looks up a resource named 'name' in the classpath. The > resource must map to a file with .properties extention. The > name is assumed to be absolute and can use either "/" or "." > for package segment separation with an optional leading "/" > and optional ".properties" suffix. Thus, the following names > refer to the same resource: > > some.pkg.Resource > some.pkg.Resource.properties > some/pkg/Resource > some/pkg/Resource.properties > /some/pkg/Resource > /some/pkg/Resource.properties > ---- > > so I suppose it could be possible to patch the > ConfigServlet.initLogging method to use a PropertyLoader > class (see above) that manages the loading of props files > accessing to filesystem or using the classloader to load > files stored into the application package (i.e.: load > com.foo.bar.config.myConfiguration.properties "resource") > > > > As a workaround I commented > > the > > log4j.configuration parameter out and moved the log4j.properties to > > WEB-INF/classes (which is the first location where log4j > looks for its > configuration > > file if nothing is specified). > > That workaround works fine as long the dbforms-app runs > alone on the > > Weblogic (and Tomcat). But weird things happen when my second > > application runs on the same server: The log4j configuration of the > > dbforms-app is ignored and the application writes its logs into the > > log4j-logfile of the second application (i.e the dbforms-applicaton > > uses the log4j.properties of the second application)! > > > > I don't know what's going on... Do you know another > "workaround". Have > > you ever experienced similar problems? Any ideas? > > > > Thanks, > > Jan. > > Regards, > Luca > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > DbForms Mailing List > http://www.wap-force.net/dbforms ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
