RE: InitServlet.java InitContextListener.java

[Mark Womack <mw...@bevocal.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>