Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)

[Joe Germuska <Jo...@Germuska.com>]

>>Just thought of one more thing: technically, since the Configurator 
>>has access to the entire ServletContext, should we have a destroy() 
>>method also?  I would kind of prefer to leave that out and keep it 
>>simple, since otherwise it might get confusing about where cleanup 
>>responsibilities lie...  but we may not be able to avoid it.  (Then 
>>again, we may be able to wait until someone asks for it/has a use 
>>case.)
>
>Yes, I can see use cases for this (such as saving current state 
>information that will be used the next time the configuration is 
>loaded).  But if you add a destroy method, haven't you just 
>recreated the PlugIn API?

More or less, yes.  That had crossed my mind.  The major difference 
being, of course, when the methods get called.  I suppose one could 
write a plugin which instantiated more action mappings, form beans, 
etc. (I bet someone already has!) but it doesn't seem very tidy...

If someone had an idea for how to coordinate the timing of calls to 
plugins to distinguish between configuration responsibilities (the 
new use case) and other plugin uses, I'd be happy to hear it.  I was 
more looking for "the simplest thing that could possibly work" to 
open up configuration along the lines of recent discussion on the DEV 
list.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org