I'm just making this up as I go, but what if there were an optional servlet init param which could consist of one or more class names, where each class implemented a "StrutsConfigurator" interface. Then in servlet.init(), the servlet could instantiate each and pass itself to the configure method (or maybe just pass the ServletContext, if that's safer or better).
I decided to take a look at this today, and it's a little bit tangly. I figure that it's not something to commit until we cut Struts 1.2.1 anyway, but here is a bit about how I'm starting and some questions. All feedback is welcomed.
I created an interface: org.apache.struts.action.StrutsConfigurator. I have no great love for the name nor insistence on it being in that package.
I wanted it to have a single method: public void configure(ServletConfig config) throws Exception;
I'm open to any strong opinions about whether it should throw ServletException instead, or anything else.
However, it's tricky to only pass in the ServletConfig, as some of the legacy code that I'm trying to move out from ActionServlet into an implementation class (currently named "ClassicConfigurator") wants access to the ActionServlet itself. Specifically, the datasources are still a member of the ActionServlet, rather than being shared in the Application Context. I have never used Struts to manage datasources and don't really plan to, but I don't want to mess anyone up. Should we move those into the ServletContext so that various configurators can get at them? Or just relax and pass ActionServlet into the configurator instead? I'd really like to avoid that if possible.
However, I now remember, we also need an ActionServlet to initialize plugins. Do I just have to bite the bullet? Or can we figure out another way? I can't think of anything which would be backwards compatible. I just liked the idea of keeping the actual ActionServlet class out of things, especially as we pull more and more functionality out of that class.
In a different vein, I was wondering about handling "internal" message resources. I was thinking about copying the pattern from ActionServlet, but there are classes (like ExceptionHandler) which do essentially the same thing but in a slightly different pattern. In the spirit of consistency, is there a "preferred" implementation pattern that we should use for this?
Assuming that all this gets straightened out, then, the final step would be to deprecate the ActionServlet init* methods which are copied into ClassicConfigurator and to re-implement the middle-part of init() to initialize one or more configurators and execute their configure methods. But maybe we'll get into that a little more later.
My first pass was pretty crude, just copying stuff from ActionServlet into ClassicConfigurator. It seems like it might make sense to make it easier for things like a configDigester to be shared, but then, perhaps its not appropriate to assume that extended config rulesets that apply to one configurator apply to another. If that's the case, well, everyone already has access to the ConfigRuleSet class which covers the basics.
Looking forward to some feedback...
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]
