You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Brijesh NK <br...@sysarris.soft.net> on 2002/09/17 05:58:16 UTC
Sub Apps
Could anybody explain SubApplication concepts in struts frame work
Thanks
brijesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sub Apps
Posted by micael <ca...@harbornet.com>.
Damn, Eddie! Nice job!
At 11:34 PM 9/16/2002 -0500, you wrote:
>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: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>Hope that helps,
>
>
>--
>Eddie Bush
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Sub Apps
Posted by Brijesh NK <br...@sysarris.soft.net>.
Thanks Eddie, for the valuable information.
-----Original Message-----
From: Eddie Bush [mailto:ekbush@swbell.net]
Sent: Tuesday, September 17, 2002 10:04 AM
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:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
Hope that helps,
--
Eddie Bush
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Sub Apps
Posted by Robert <rm...@bull-enterprises.com>.
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:ekbush@swbell.net]
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:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
Hope that helps,
--
Eddie Bush
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sub Apps
Posted by Eddie Bush <ek...@swbell.net>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Hope that helps,
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>