On Tue, 15 Mar 2005 11:23:09 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >Joe had mentioned wanting to move module init code to the > >ModuleConfigFactory. > > I did? ;-) > > Seriously, though, I don't quite remember the details of that > discussion -- do you happen to have any pointers to the archives? >
It wasn't really discussed, just mentioned. :) The point was to move the code out of ActionServlet more than to move it into ModuleConfigFactory. http://marc.theaimsgroup.com/?l=struts-dev&m=110908681127847&w=2 > I think in general, the idea is to make ActionServlet do little more > than receive requests and broker them off, with the more general idea > of making Struts clean of unnecessary dependencies on the Servlet > API. Thus, moving as much setup as possible out of there seems > theoretically good, although I don't know if it needs to be the first > step -- considering how Action and ActionForm have direct > dependencies on that API, it may be a lot of ceremony for relatively > little payoff. > I agree with the idea. In my work, there exists an SOA-like framework and different teams have been using different ways to get to the services. Some used HTTP, some had custom protocols, some used JMS, some used custom JMS frameworks. Testing client apps was tricky, so I came up with a mock framework where you could plug in a mock service and configure how it would interface with clients - HTTP, JMS, in-house protocols, etc. >From a Struts perspective, this would be like writing an Action class and specifying in struts-config whether that Action class supports servlets, web services, JMS, or all of them or any combination of these and others. A protocol-specific object would accept requests, populate the ActionContext, then send it to a module's RequestProcessor for processing. After the request is processed, the RP sends it back to the protocol-specific object to send back the response in an appropriate way. Or did I just venture too far from what you were trying to picture? > As a general strategy, I think stuff in ActionServlet now should move > off to a "StrutsApplication" which would deal with bootstrapping and > with assigning requests to modules for processing. (As today, the > per-module request processor would do the bulk of the work, referring > to its own ModuleConfig for necessary information and resources.) > > Was there some detail that I'm forgetting now which makes the factory > the right place for it? But assuming I was harping on the same old > riffs, I was probably somehow trying to get at "reduce direct > dependencies on Servlet API". > > But most importantly, I think it would be best to get decent working > code in place; we will be continually refactoring, so adding/changing > stuff where it already is would be no great sin. And if we don't > have many use cases in mind for non-Servlet Struts usage, we may make > some errors in generalizing certain things, so no need to rush. > (Always remember, though, that unit testing is a non-Servlet Struts > use case, so just thinking about how to make things more testable may > help reach a good generalization.) > Well, moving what we can from ActionServlet to ModuleConfigFactory doesn't really help testability that much right now. It's just to reduce the size of ActionServlet and move code that doesn't need to be there. It doesn't have to be the ModuleConfigFactory either, though right now, that's the best fit. > On the other hand, if it seems easy and straightforward to make an > incremental improvement as part of this process, great! > This is how I felt about putting ActionContext in a ThreadLocal variable -- an incremental steps towards POJO Actions. :) Hubert > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
