Well, when you are using a repository selector, the idea is that you have Log4j in a position where it is not part of your app, but part of the server; otherwise there's no point to using a repository selector. In order for a server wide instance of Log4j to service many apps without each of them stomping on each other's logging, each app needs to be assigned its own logger repository. On the other hand, if you deploy your app with Log4j in WEB-INF/lib (and use child-first classloading behavior), you can just use the default logger repository since your app will be the only one utilizing the instance of Log4j.
The only reason to set the repository selector from your own app's servlet context listener is to guarantee that a global version of Log4j has its repository selector set so that your app will log to its own logger repository instead of the default one (in case it is using a global version of Log4j and nothing else has set the repository selector yet). Of course, ideally, this would be done via the command line when the server is started. However, not everyone has access to modify the server startup script.
You seem to be running into the case where the instance of Log4j is global (probably because of JBoss' often problematic single classloader design) and the custom repository selector is part of your app (also global because of JBoss' classloader behavior). Once your app gets unloaded, you've got problems. Log4j still exists, but it can't find its repository selector (or the app fails to undeploy because of the reference).
The solution is to deploy your custom repository selector alongside the global instance of Log4j, not with your app. And if you have access to the JBoss startup script, you can set the -D property to set the repository selector when JBoss starts up (sorry, can't recall the system property name to set ATM).
The point of the guard is to disallow apps from changing an already set repository selector. This is the business of the server. If the server holds the guard, it can provide a configuration mechanism whereby a controlled change can happen. But having any given app change the respository selector at any time during the running of the app server would break logging for any other app than the one resetting the repository selector. Make sense?
Jake At 07:09 AM 9/15/2006, you wrote: >Hi, > >what is the purpose of the guard in setRepositorySelector()? I miss a >possibility to reset the LogManager repository selector to it's default >value (including resetting the guard). Why? I deploy my application in >JBoss. I want to have separate logging for my application so I use the >setRepositorySelector() (see http://www.qos.ch/logging/sc.jsp) in my >servlet listener. However when my application is undeployed, I need some way >how to reset the repository selector to it's previous value (or default), >otherwise JBoss throws lots of exceptions clearly because my implementation >of RepositorySelector.getLoggerRepository() was unloaded. Currently I fixed >the problem with reflection - I reset the LogManager.guard to null. It works >but do I sit on a timing bomb? > >Thanks, Jan > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
