Thanks for the replies. I don't think the log4j.configuration env var helps me here much because I want a single log4j.xml for all applications, not a different log4j.xml for each app
Greg Brown wrote: > > You'd need to regenerate your JARs for sure, but if your build script is > set up right that shouldn't be a huge problem. For example, the last > project I did used Ant to assemble the JSPs, applets, etc. into a WAR > file. We simply ran "ant deploy" to regenerate the WAR and redeployed it > to the server. Ant was also used to sign the JARs before putting them into > the WAR file. > What you describe is exactly what I do now in my build procedures however... My issue here is that currently I have no build scripts that go with my installable software. After the software is installed someone may have issues and need to turn the log level up (as an example). They will have no way to re-sign the jar after the xml update. I think my current approach is to simply put a "template" log4j.xml in each war that uses it during build time. Then have certain fields (such as log level) be a configurable property that gets passed to the applet and overriden in code. this is the only solution that I can think of that "may" give me desirable behavior. Will let you know how that works out. -- View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Help-understanding-classpaths-codebase-with-applets-tp914940p915277.html Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
