Apologies for the late reply. When it snows in the South, it is chaos :).
Comments inline. Mitesh Mehta S1 Corp (http://www.s1.com) > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 02, 2002 2:39 PM > To: Struts Developers List > Subject: Re: [Design Discussion] Multiple Controllers Per Web App > > > I don't understand why Stoehr Sukachevin's approach would not have the > same problem with the extensions. Is because of the "context" > attribute > in the tags? That would seem like a lot of rework times the number of > applications that need to be reworked. I meant rework to the existing Struts architecture, not the applications. Stoehr's approach also supports the notion of a default "app" so an existing app can remain oblivious of other sub-apps. In other words, his approach is backwards compatible. For forward going apps a "context" has to be defined in the JSP for the tags to pick-up the right info. I haven't entirely analyzed Stoehr's implementation but the fact that I did not have to do anything significant to any of the extensions (besides changing their inheritance from the core Struts classes to Stoehr's subclasses) in order to make them work under his framework does say something. To be fair, he did have to subclass a few Struts classes and tags. Besides, it depends on Struts subclasses, so it is inherently backwards-compatible since it does not modify the Struts framework itself in any way. > > As I understand it, there is a separate servlet controller for each > sub-application, and each of those would load their own resources, > including the message resources. The default controller "simply" > dispatches request to the sub-controller, which are just other > ActionServlets. If you are talking about Stoehr's framework, that is not accurate. Each controller is directly defined in the web.xml with its own path-mapping (similar to Craig's application context). So there is no dispatching by the default servlet. The default servlet just stays with the .do extension. That is what allows all the Struts extensions that map to a single controller to automatically take advantage of the multiple controller split. > > Your point about the Tiles and Validator extensions is well > taken. Many > sub-applications would not want to share these. Perhaps we > will finally > need to integrate Oleg's service manager, so multiple copies can load > them. Then they would also have to be updated to look for the prefix > using the new RequestUtil method, but that might be > relatively trivial. Not sure what the service manager is. I do not see it on the list of extensions. Maybe it is in the struts-dev archives. At the risk of sounding like a broken record I will reiterate that any approach which requires Struts extensions to do a lot of rework in order to support splitting should be closely examined. It takes away from the power of Struts if the large number of extremely useful extensions out there are now left behind in some sense. I recognize the general problem that most forward development of a framework such as Struts can have such impact. But in this specific case, there is an alternative that has been proven and it should at least be considered seriously. > > -Ted. > > > Mitesh Mehta wrote: > > > > Thanks for addressing this much-desired feature. I have > read the archives > > on this thread (last entry around 8.30am today) so > hopefully I am not > > repeating anything here. > > > > While this is a step in the right direction, I think it > does not exploit the > > full potential of having multiple struts controllers. IMO, the most > > important requirement for supporting multiple controllers > (sub-apps) is as > > follows. > > > > "Development and Deployment management: The underlying > resources of a > > Struts app should be manageable and deployable by separate > teams as a single > > web-app without requiring development or runtime > inter-dependencies." > > > > The proposed approach addresses splitting of the > struts-config.xml resource. > > But Struts being highly extensible can and does pull in > other resources (for > > e.g., tiles-definition.xml, message resource bundles). In > our project, we > > have also changed the Winterfeldt validation framework so > the validation.xml > > is loaded via a controller servlet configuration parameter > rather than being > > a separate servlet of its own. These other resources also > need to be split > > up along the same lines as the struts-config.xml. In other > words, the > > multiple controllers idea would be really powerful if the > various Struts > > extensions and their underlying resources can also > participate in it. > > > > If one follows that line of reasoning there are 2 options available. > > > > 1. Use the current approach but modify all extensions to > take advantage of > > the concept of a "sub-app context". Lot of rework, I think. > > 2. Rethink the current approach in favor of something that > is more like the > > Multi-Controller extension from Stoehr Sukachevin. > Practically no rework > > for any of the extensions. > > > > There is an excellent e-mail thread titled "Multiple > ActionServlet instances > > in a web app" on the struts-dev group from March 2001 that > discusses the > > multiple servlet approach in great detail. The message at > > http://marc.theaimsgroup.com/?l=struts-dev&m=98525810803935&w=2 is probably > of most interest. > > Although having multiple action servlet instances does require more memory, > I think the ease of management for large projects more than compensates for > this. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
