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:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>

Hope that helps,


-- 
Eddie Bush




--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>