I just got around to reading this and glad I did. At the moment I'm still stuck in the 1.0 world and wasn't looking forward to figuring out the 1.1 ways, but this has certainly helped a bunch. This is the kind of thing that should be in the docs (if it isn't already).
- Robert -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 11:34 PM To: Struts Users Mailing List Subject: Re: Sub Apps On a very high-level, yes :-) Back in the old days (Struts 1.0), you used to have one application. You configured the action servlet in web.xml, and told it where to find your one (and only) struts-config.xml file. This one file was where all of your application config was kept. Unfortunately, there was contention when multiple people needed to update the configuration file. ... along comes 1.1 (beta) Now, you can have as many configuration files as you have modules. Each module will (presumably) be handled by one team, so contention is less. Each module can be independently developed - caring nothing about the others, unless it has to. This is better for multi-developer settings. To ease the transition, there is always one module -- the default module. That module lives (speaking in URI-terms) at http://mydomain.dom/appContext/. All other modules live at http://mydomain.dom/appContext/module/. By default, all paths are treated as relative to the module context. Since this happens to be the same as the applciation context for the default application, struts 1.0 applications should be able to easily migrate to 1.1. You could then convert over to the new modules strategy "one piece at a time". That a "birds-eye view" of sub-applications. Is that what you wanted? Need more details? Oh, what the heck - here: It's really quite easy to implement. You just ... well, in your web.xml, you do something like this: <!-- Default Sub-Application Config --> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/conf/struts-default.xml</param-value> </init-param> <!-- ModuleA Sub-Application Config --> <init-param> <param-name>config/modulea</param-name> <param-value>/WEB-INF/conf/struts-moduleb.xml</param-value> </init-param> <!-- ModuleB Sub-Application Config --> <init-param> <param-name>config/moduleb</param-name> <param-value>/WEB-INF/conf/struts-moduleb.xml</param-value> </init-param> Each file is a struts-config file. What you're actually doing when you specify the config elements, is saying "make this module live at <app-context>/<module>". So, from the example above, we would reach module a by using a URL like: http://localhost:8080/myApp/modulea/index.do We could reach moduleb by doing something like: http://localhost:8080/myApp/moduleb/index.do Both of my examples depend on one very important key: You should have an action setup for each of them that maps to /index. Provided that you have done that, you'll have good results. Let's look at one of the struts-config files: <struts-config> <form-beans/> <global-forwards> <forward contextRelative="true" name="toDefault" path="/index.do" redirect="true"/> <forward contextRelative="true" name="toModuleA" path="/modulea/index.do" redirect="true"/> <forward contextRelative="true" name="toModuleB" path="/moduleb/index.do" redirect="true"/> </global-forwards> <action-mappings> <action path="/index" parameter="/default/moduleindex.jsp" type="org.apache.struts.actions.ForwardAction"> </action> </action-mappings> <message-resources key="org.apache.struts.action.MESSAGE" parameter="com.mycompany.struts.module.DefaultResources"/> </struts-config> The global-forwards gives me a way to get from this sub-application (this is a cut-down excerpt from my struts-default.xml) to my other sub-applications. Every one of my struts-<module>.xml files has these very same global-forwards. I just copied and pasted them from one to the other. I made them all context-relative (that means -- interpret this path as though it is relative to the APPLICATION-context -- not the module-context. Struts, by default, will interpret your paths as being relative to the module-context). There are other ways to change sub-applications too. org.apache.struts.actions.SwitchAction will do this for you. Be sure you give it both required request parameters: prefix (the module name preceeded by a '/' -- as in /modulea) and page (if you do a type-o like I did, and get an exception saying to use prefix and path just ignore it. It is incorrect. I already filed a bug and submitted a patch). To make navigation among modules easy, all of them have an index action. That is the primary entry-point from one module to another. I may or may not have additional links into other sub-applications, depending on what my requirements are. That's something you'll have to judge for yourself. You'll notice some convention I use. Each of my modules has it's own directory under the application root. I keep things relating to a given module in it's own directory. I also have a common directory which houses things that get shared (like layouts etc). Unfortunately, I haven't managed to make Tiles work correctly with sub-applications yet. I may be doing something wrong. That's why you don't see the TilePlugin being installed. I just use JSP pages for my definitions. I haven't tried the Validator out with them yet -- haven't got along that far with my prototype. I guess I should. I wasn't going to go into so much depth, but I'm nearly certain the high-level description I started out with wasn't what you were looking for. Oh - one last note - you *must* go through the controller (ie through an action) if you want your request to be associated with one of the non-default sub-applications. My experiments have shown that I can view JSP pages directly, and have resources pulled back, but those resources are always the ones for the main (default) sub-application. Brijesh NK wrote: >Could anybody explain SubApplication concepts in struts frame work > >Thanks > >brijesh > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > Hope that helps, -- Eddie Bush -- 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]>
