This thread seems to have taken a turn into something I'm interested in; too bad the subject didn't change with it so I could have started following sooner.
You really didn't miss much yet...
I really don't like methods that throw Exception so I like ServletException better.
No problem. I just really don't like many layers of wrapper exceptions that make it hard to get to the root of the problem. ExceptionUtils in commons-lang helps, of course. Anyway, in this case, it's unlikely that there will be many layers, so consider that changed.
IMO, Struts datasource handling should be deprecated and removed. It had it's place in the past but now Struts has no business "managing" datasources; that's the containers job and most of them do it better than Struts. I would like part of Struts 2.x to focus on simplifying users' lives and removing this feature follows in that spirit; but that may be for another thread.
Well, I was thinking about doing this refactoring in a pre 2.x timeline and maintaining compatibility. But I agree that datasource handling should be left out of Struts.
At this point isn't ActionServlet merely init. code plus delegation to the RequestProcessor? In the future ActionServlet may just be delegating to init. classes and to Commons Chain so I agree that we should probably limit passing it around. It's really more of a starting point for a request than anything else.
Yes, it is, but the PlugIn interface still calls for it. Of course, the Servlet is already storing itself in Application context under Globals.ACTION_SERVLET_KEY, so I suppose we could leave it out of the interface while still maintaining backwards compatibility. Since ActionServlet.datasources is protected and I was putting "ClassicConfigurator" in the o.a.s.action package, that's really all that's necessary to deal with both of these issues.
How does that sound?
Of course, ActionServlet is tangled up in the API for Action and ActionForm too, so we probably aren't going to really be able to clean that up before Struts 2. Still, I think it's good to point the direction. Besides backwards compatibility, in those cases, is there any reason we should be passing the Servlet and not just the ServletContext?
While we're on the thread, I remembered one other thing: right now, the configuration freezes each module config. I've never been 100% clear on why Struts uses 'freeze' to lock things down. Is there any legitimate reason for more than one configurator to be involved in setting up a ModuleConfig? If so, we need to either take out the freezing or push it up into ActionServlet to do after it has given each StrutsConfigurator a chance to do its thing. In my "draft", I just left the moduleConfig.freeze() inside the "ClassicConfigurator", but I wanted to check on this question.
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.)
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]
