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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
