Hey Jake, > Looks like you committed the correct code and added the change that I > suggested, so all looks good! Yeah!
> The only problem with the > names might be > that we might want to have multiple initializer servlets and servlet > context listeners. Not sure if that is in the plans, but if > it is, then > naming my stuff generically as "InitServlet" and > "IinitContextListener" > doesn't leave room for new ones to be added. Just a thought. > If mine are > going to be the only servlet container initializers, then there is no > problem with the names. I can't imagine that we will have more than one of each, but then maybe my imagination is lacking in this area. The goal is to provide a useful set of general purpose servlet related classes that themselves can be used or at least serve as excellent examples should folks need to write their own. So, I think we are ok. > I'd love to hear some suggestions on how I might implement > #1. If we added > "doIdempotentInitialization()" to the RepositorySelector > interface, then we > could set a system property as to what implementation class > gets used and > use a Factory to grab the assigned selector to call > "doIdempotentInitialization()". Does that sound appropriate? > Or should we > leave the RepositorySelector interface alone and create a new > interface > such as RepositorySelectorInitializer which contians > "doIdempotentInitialization()" and make any implemented > repository selector > implement RepositorySelectorInitializer in addition to > RepositorySelector? Just looking for ways to stay compatible > with Log4j1.2 > and get the functionality we want in Log4j1.3. We'll have to explore this. I like the factory idea as a way of hiding the details from the servlet code. Did we decide to add doIdempotentInitialization() to the RepositorySelector interface, or still thinking about it? I think we need to decide on how that is handled before generalizing the servlet code. > As far as generalizing the logic to make it able to be > reused, that's a > good idea. I guess we'd then need to move the logic out into > a new regular > class which gets instantiated in very much simplified > servlets and servlet > context listeners. Let me know if you have any design ideas > for this. I > want to make sure that what we come up with matches the > design philosophy > of Log4j as a whole. I ws thinking we could move the appropriate bits of code into a "common" class as static methods. Then there is no need for another object instance. One version of the method takes a ServletContext another version might take something else not so servlet oriented. I have a similar, less complex version I use here at work. I need to look at your code closer to suggest a factoring. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>