At 23:39 22.12.2002 -0600, Jacob Kjome wrote:
Yep, this seems to work great! I've tested the code you attached here and it works flawlessly, except....RepositorySelector is designed with one and only one active RepositorySelector in mind. If it is set, then you are stuck with it. A web-app cannot pick and chose its RepositorySelector, that is a working assumption upon which the rest is built. One cannot meaningfully circumvent this restriction.
I see one possible issue with this. Mark wanted a Log4jInit servlet which was flexible enough to allow configuration of which repository selector to use. However, the first application installed on the server which uses Log4j and a custom repository selector will force that RepositorySelector on all the rest. That might be a bit confusing. Think about a server which serves lots of webapps with a few using Log4j and, of those, a few attempting to use a custom repository selectors. However, a couple apps want to use Log4jCRS and the other couple want to use Log4jJNDI. The first one installed will set its preferred selector and the others will be stuck with that decision no matter which one they preferred.
Also, the doIdempotentInitialization() will crap out on subsequent calls to custom repository selectors that weren't the lucky one to get set as the active repository selector. Consider this....
public static void doIdempotentInitialization() {
if(!initialized) {
Object guard = new Object();
LogManager.setRepositorySelector(singleton, guard);
initialized = true;
}
}
if it can't set its repository.
If Log4jCRS was the one set as the repository selector, subsequent calls to the Log4jCRS.doIdempotentInitialization() will just skip setting the repository selector with the guard because "initialized" will have already been set to true. However, calls to Log4jJNDI.doIdempotentInitialization() will crap out because "initialized" will still be false so an attempt to set the repository selector will happen, but being that the guard is different than was already set, the set will fail with an "<http://java.sun.com/products/jdk/1.3/docs/api/java/lang/IllegalArgumentException.html>IllegalArgumentException". Unless that code is wrapped with a try/catch, the method will bomb making lots of people unhappy and confused as to why things aren't working.
I guess this is where having the container set the repository selector upon container startup might be applicable.
So, I think we need to discuss how valuable having a Log4jInit servlet that chooses its own repository selector is since it is only a choice for the first app. Secondly, the Selector.doIdempotentInitialization() is aptly named *only* in the case where there is only one possible custom repository selector that could be called. Calls to various other selectors' doIdempotentInitialization() are not idempotent with respect to each's call to LogManager.setRepositorySelector(singleton, guard). Another name might be in order to better describe what that method does...and maybe it should be in the RepositorySelector interface? Thirdly, if nothing else, that method should do the following for safety....
public static void doIdempotentInitialization() {
if(!initialized) {
try {
Object guard = new Object();
LogManager.setRepositorySelector(singleton, guard);
initialized = true;
} catch (IllegalArgumentException iae) {
//either ignore the exception or log the fact that the setting of this
//custom repository selector failed because another had been set previously
// and maybe we should set "initialized" to "true" in here so this exception doesn't
// occur again in this class
}
}
}
Yep. -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
