At 17:10 15.01.2002 +0000, Adrian Brock wrote:
>Hi Ceki,
>
>Thank you for your response. I'll snip your e-mail, since
>you've already posted the original to this list.
>
>>If you like, we can work together to implement this JBoss specific
>>RepositorySelector
>
>Yes, I'm new to 1.2, I'm still at the investigation
>stage. I've downloaded the alpha, looks like I need to do some testing. :-)
>
>>If we want static Logger variables to depend on the application, then
>>one *possible* approach is to let the ClassLoader assigned to the
>>application contain a LoggerRepository field.
>>...
>>If however we say that static Logger variables are not allowed, then
>>the approach of setting the repository each time is reasonable
>>although it might be wasteful. If we know that there will be one
>>LoggerRepository per application we might as well take advantage of
>>that knowledge.
>
>Good point, I need to cater for static instantiation of Loggers.
>I'm not sure I understand the last part, unless you are saying all
>loggers should be static and created during class loading?
No, no I am not saying all Loggers should be static. It is just very
common possibility. The last part about taking advantage of "that
knowledge" has to do with my assumption about one repository per
application. In other words, I was assuming B).
>The interceptor technology within JBoss means the switching of
>repository on method calls can be optionally configured by the deployer
>for applications that need it, i.e. loggers created within the
>business methods.
>
>I'll have to think about this some more. What about Loggers created
>in the constructor when preloading a pool or deserialization code for
>objects sent over the wire?
>The static final Logger, is the most likely for enterprise beans.
>All static fields have to be read-only in the spec, and it
>doesn't really form part of the bean's state.
>
>Re: Configuration
>This is a grey area to me.
>My only thought is that the deployer chooses the repositories.
>
>They may choose:
>A) to run everything using the JBoss repository i.e. as now
>B) one repository per application
>C) have just two repositories one for JBoss and one for applications
>D) a mixture of the above
I suggest we go for option B). (There will be also a repository just
for JBoss.)
This is not the most sophisticated approach but it is a good start
which will satisfy the vast majority of users. Would you agree?
Anyway, if we choose option B, then the RepositorySelector will return
the LoggerRepository assigned to the applicaiton. Here is a possible
implementation:
public class JBossRepositorySelector implements RepositorySelector {
public LoggerRepository getLoggerRepository() {
// this is where I need your help...
application = findInvokingApplication();
LoggerRepository rep = hashTable.get(application);
if(rep == null) {
rep = new Hiearchy(new RootLogger(Level.DEBUG));
configureNewlyCreatedRepository();
}
return rep;
}
}
The only unknown is the implementation of findInvokingApplication()
method. The getLoggerRepository method must be able to discover the
application invoking the LogManager. (LoggerRepositories are only
called from within the LogManager.)
One possible approach is to associate a...
oops, while I was writing this email your answer came in. Yep,
Thread.currentThread().getContextClassLoader() is the way to go
although this was not clear to me before I saw your message.
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
