Hello Adrian, I very much apologize for not having responded earlier. My response is below intermixed with your message. On 2002-01-11 19:40 Adrian Brock wrote: > Hi log4j-user, > > I was pointed by Aron Kramlik to this mailing list. > > I'm looking at implementing the RepositorySelector into JBoss. I only > found out about this class and 1.2 about 1 hour ago, so apologies if > my questions sound naive. I've looked at the javadocs, I don't think > this is in the manual yet:-) I like the comment in the javadocs about > JBoss/Tomcat, are you making sure we are paying attention? Indeed, the whole idea of the LogManager, RepositorySelector and LoggerRepository is geared towards servlet containers and J2EE application servers. > As far as I understand this, we implement RepositorySelector and add > this to the LogManager. Our RepositorySelector can then use one > repository inside the container and an application configured one when > we invoke its methods. Is this correct? You are correct to assume that JBoss would install its own RepositorySelector into the LogManager. If you like, we can work together to implement this JBoss specific RepositorySelector. Yes, a JBoss RepositorySelector would return one LoggerRepository for JBoss iteself and one LoggerRepository per application. > We do something like: > > jbossSelector.setContext(application.getRepository()); > invokeApplicationMethod(); > jbossSelector.setContext(jbossRepository); Well, yes that's the general idea. However, setting the LoggerRepository at the time bean methods are called is a bit late in the game because most users will have a static Logger variable which is set when the bean class is loaded. It follows that the RepositorySelector must know how to return the correct LoggerRepository early in the game, that is, when the bean class is loaded into memory. 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. Let me note that the LoggerRepository is instantiated and chosen be the Application Server, not the J2EE application itself. > Then we need to supply a means to configure > application.getRepository() which will probably be jbossRepository > when not configured. Do we need to provide a configuration > mechanism or is there another way? I think that most users will want to have a logger repository per application. JBoss should perhaps offer two settable options. A first would specify the configuration file to use in order to configure the LoggerRepository. A second option would specify the org.apache.spi.Configurator implementation to use to parse the configuration file specified in the first option. > Final question. I scanned the December/January mail archive but didn't > spot this. What didn't you spot? By the way I suggest we continue this discussion on this list (log4j-dev). Is that OK with you? > 1.2 when? I am sorry but I cannot give you a firm date. Regards, Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
