I would like some feedback on the subject of multiple controller servlets. I have seen some of the previous discussion in the archives. The basic problem has to do with modularity - both in the runtime and at development time. The current solution of multiple config files certainly solves the many of the development issues esp. that of managing a single large config file, but what about other resources (messages). When I first started using struts my first impulse to deal with modularity was to have multiple controllers and I was quite surprised that I could not do this. The idea of multiple controllers each self contained seemed quite natural. I have since developed a patch that works quite well. But before a submit it I would like to know: Does anyone think this is a bad idea or that the current solution is complete enough? Is there a problem with the basic design as detailed below:
The basic problem in the current code is that the ActionServlet stores some attributes in the ServletContext; other servlets overwrite these attrs. The solution is to have one ActionServletContext per deployed action servlet. This context is stored in the ServletContext under a unique key for each controller. Those attrs that were stored in ServletContext are stored instead in this "local" context. A particular context becomes "active" at request handling time. The first thing the action servlet does is to put its local context into the request object using a statically defined key (Action.CURRENT_CONTEXT_KEY). Thus the other part of this patch is updating the access to the application scope attributes. These mostly reside in the taglibs (though I bet someone accesses them in their Action class impls). The patch was to create helper methods in RequestUtils that returned these atttrs directly (ex. RequestUtils.getActionForwards()). These helper methods then access the attrs out of the local context in the request using the original keys (ex. Action.ACTION_FORWARDS). Now clearly there are times when the active context in the request is not appropriate: - Welcome pages that were not served by a controller, hence there is no active context stored in the request. - Forwarding to jsps that are not part of the "module" - like back to a welcome page. I handled the first problem by having a "primary=true" initparm for a particular action servlet. What this means is that the local context attrs for this servlet are dumped into the global ServletContext at init() time. The RequestUtil helper methods understand to look in the global context if no local context is found. This would also be done for message lookup (no msg in locally defined resources, look in global resources). The solution to the second problem seems to require programmer intervention (not good): either he explicitly clears the local context out of the request before forwarding to an "external" resource or uses a special forward class that knows to do so. However, it can be argued that the welcome page is the only page that one should even consider forwarding to outside the context of a controller servlet; access to other jsps should go through actions the have been configured with the "forward" attribute. This way each "module" has complete control to all its resources. Since I am new to Struts I am no doubt missing things here. Thankyou for any comments. Tim W Wilson Eclipse WSED Architecture & Development internet: [EMAIL PROTECTED] (919) 254-0029 (TL 444-0029) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
