At 20:51 15.01.2002 +0000, Adrian Brock wrote:
>Hi Ceki,
>
>My brain is almost working, just very slowly :-)
>A quick scan of the LogManager source and it is obvious!!!!
That was very quick.
>You associate the LoggerRepository with the application's classloader
>when that is created at deployment. I thinks that's what you said
>in your last e-mail, I just didn't get it.
Exactly! Associate a LoggerRepository with the application's
classloader when it is created at deployment.
I said we could associate a LoggerRepository with application's
classloader. I was actually missing the "at deployment" part. D'oh!
The picture is even clearer now.
>The RepositorySelector should be something like:
>
>
>// Use a weak map for garbage collection of removed deployments
>private WeakHashMap repositories = new WeakHashMap();
>
>public associate(ClassLoader cl, LoggerRepository repository)
>{
> repositories.put(cl, repository);
>}
>
>public LoggerRepository getLoggerRepository()
>{
> // Configured repository?
> LoggerRepository result =
> repositories.get(Thread.currentThread().getContextClassLoader());
>
> // No repository specified use the default
> if (result == null)
> result = jbossRepository;
>
> return result;
>}
Hmm.. were you reading my mind? If you did, then how do you do it?
Seriosuly, I think we can expect JBoss to remove the cl/repository association
from the hashmap when an application is removed. If that were the
case, there would be no need for a WeakHashMap, a normal HashMap would
suffice.
IMHO, "result" should never be null. Consequently, there would be no
need to fall back on the default jbossRepository. Here I am assuming
that there is always one repository per application. The repository would
not be a user selectable option. Anyway, I am probably wrong on this one.
>Very nice, very clean, very easy and very powerful :-)
Whoa, thanks. Well, I think it would get the job done. That's all. :-)
>In fact it is so good, it can be used to separate other parts of
>JBoss if required. e.g. a user deployed service or the embedded
>webserver.
??? Isn't the JMX bus supposed to solve all these problems?
>I just need to worry about the form of the configuration...
Configuration is the easy part. Once you know which LoggerRepository
to associate with which application, you just configure the LoggerRepository
by invoking the configure method of the appropriate configurator.
The interface org.apache.log4j.spi.Configurator which is implemented
by both the PropertyConfigurator and DOMCOnfigurator has a method
called doConfigure which takes an InputStream *as well as* the
LoggerRepository to act on.
At application deployment time we would call the following method:
void configureLoggerRepositoryAtApplicationDeployment(LoggerRepository rep,
Application app) {
URL url = app.getLoggingConfigurationResourceUrl();
String clazz = app.getLoggingConfigurator();
Configurator configurator = (Configurator) Class.forName(clazz).newInstance();
// et voila, we can now declare victory...
configurator.doConfigure(url, rep);
}
This method is not very robust but you get the general idea. All you
need is to be able to retrieve the two parameters specific to the
application
1) The URL of the log4j configuration file to use,
2) The configurator class. Here we can suppose a default class, say
PropertyConfigurator or DOMConfigurator.
and then configure its LoggerRepository. Does that make sense?
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
