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 alot of rework times the number of applications that need to be reworked.
As I understand it, there is a seperate 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. 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 mutiple 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. -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]>
