You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Thinh Doan <td...@twjconsulting.com> on 2002/09/06 19:50:01 UTC
sub-app switch
is it possible to switch to a sub-app with <html:link forward="Name in
subapp struts-config"> from outside the current sub-app or the default app?
TIA,
Thinh
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Tuesday, August 13, 2002 10:59 PM
To: Struts Users Mailing List; tdoan@twjconsulting.com
Subject: RE: Struts architecture performance
On Tue, 13 Aug 2002, Thinh Doan wrote:
> Date: Tue, 13 Aug 2002 22:19:24 -0500
> From: Thinh Doan <td...@twjconsulting.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> tdoan@twjconsulting.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts architecture performance
>
> Craig,
>
> >>you can now divide a monolithic Struts based application into
> "sub-applications"
> >>(they are going to end up being called application modules), each with
its
> >>own struts-config.xml file.
>
> Do you have additional info. on how to setup sub-apps with multiple
> struts-configs in 1.1b2? Thank you,
>
This definitely needs to be documented better, but it is actually
amazingly simple:
* You must be using extension mapping for the controller servlet
(i.e. "*.do" style instead of "/do/*" style).
* All requests must go through the controller servlet. No linking
directly to JSP pages (this restriction will be lifted once
Struts mandates Servlet 2.3 as the base platform so we can use
filters).
* The resource path to the struts-config.xml file in Struts 1.0.x
is specified in the "config" parameter to the controller servlet.
In 1.1, this continues to be true, but it now refers to the "root"
application module that is used if no other application modules are
installed. Thus, existing apps continue to work.
* Several things that used to be configured with other servlet init
parameters are now configured in the new <controller> element in
the struts-config.xml file for a module. The old parameters continue
to work, but they are deprecated and only apply to the default module.
* To add an additional application module, simply configure an additional
servlet init parameter for the controller servlet. To have a module
whose context-relative prefix is "/foo", then the init parameter name
would be "config/foo".
* If you do this, all paths that (in Struts 1.0.2 config files) were
context-relative now become module relative. Say you have a forward
declaration like this:
<forward name="Main Menu" path="/mainmenu.jsp"/>
In the default module, Struts will prefix this with the context path
for your web application, so the path would be something like
"/myapp/mainmenu.jsp". However, if this struts-config.xml file were
pointed at by the "config/foo" init parameter (so that the module
prefix is "/foo"), then the path will automatically be converted to
"/myapp/foo/mainmenu.jsp" instead.
* The net result is that any given struts-config.xml file should be able
to be used -- unchanged -- as either the default module (equivalent
to the only module in a 1.0.x environment) or as an app module. The
only thing you have to do is put all the JSP pages (or other resources
used for the view layer) into a subdirectory that corresponds to the
module prefix.
In the past, it was often necessary, on very large scale applications, for
different development teams to fight over the one-and-only copy of
struts-config.xml. Now, each module can be developed independently -- and
you can choose whether or not to combine them into a single webapp based
on whether or not you need to share session information between modules.
It's a very powerful paradigm.
Try it, you'll like it :-).
> Thinh
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RES: sub-app switch
Posted by julio <ju...@softsite.com.br>.
I don´t know if its the best way, but you could create an entry in the
struts-config.xml, with the action SwitchAction and redirect in your
page to that path to do the work.
________________________________
Julio Cesar
SOFTSITE Tecnologia
Fortaleza, CE, Brasil
http://www.softsite.com.br
________________________________
-----Mensagem original-----
De: Thinh Doan [mailto:tdoan@twjconsulting.com]
Enviada em: sexta-feira, 6 de setembro de 2002 14:50
Para: Struts-User
Assunto: sub-app switch
is it possible to switch to a sub-app with <html:link forward="Name in
subapp struts-config"> from outside the current sub-app or the default
app?
TIA,
Thinh
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Tuesday, August 13, 2002 10:59 PM
To: Struts Users Mailing List; tdoan@twjconsulting.com
Subject: RE: Struts architecture performance
On Tue, 13 Aug 2002, Thinh Doan wrote:
> Date: Tue, 13 Aug 2002 22:19:24 -0500
> From: Thinh Doan <td...@twjconsulting.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> tdoan@twjconsulting.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts architecture performance
>
> Craig,
>
> >>you can now divide a monolithic Struts based application into
> "sub-applications"
> >>(they are going to end up being called application modules), each
with
its
> >>own struts-config.xml file.
>
> Do you have additional info. on how to setup sub-apps with multiple
> struts-configs in 1.1b2? Thank you,
>
This definitely needs to be documented better, but it is actually
amazingly simple:
* You must be using extension mapping for the controller servlet
(i.e. "*.do" style instead of "/do/*" style).
* All requests must go through the controller servlet. No linking
directly to JSP pages (this restriction will be lifted once
Struts mandates Servlet 2.3 as the base platform so we can use
filters).
* The resource path to the struts-config.xml file in Struts 1.0.x
is specified in the "config" parameter to the controller servlet.
In 1.1, this continues to be true, but it now refers to the "root"
application module that is used if no other application modules are
installed. Thus, existing apps continue to work.
* Several things that used to be configured with other servlet init
parameters are now configured in the new <controller> element in
the struts-config.xml file for a module. The old parameters continue
to work, but they are deprecated and only apply to the default module.
* To add an additional application module, simply configure an
additional
servlet init parameter for the controller servlet. To have a module
whose context-relative prefix is "/foo", then the init parameter name
would be "config/foo".
* If you do this, all paths that (in Struts 1.0.2 config files) were
context-relative now become module relative. Say you have a forward
declaration like this:
<forward name="Main Menu" path="/mainmenu.jsp"/>
In the default module, Struts will prefix this with the context path
for your web application, so the path would be something like
"/myapp/mainmenu.jsp". However, if this struts-config.xml file were
pointed at by the "config/foo" init parameter (so that the module
prefix is "/foo"), then the path will automatically be converted to
"/myapp/foo/mainmenu.jsp" instead.
* The net result is that any given struts-config.xml file should be able
to be used -- unchanged -- as either the default module (equivalent
to the only module in a 1.0.x environment) or as an app module. The
only thing you have to do is put all the JSP pages (or other resources
used for the view layer) into a subdirectory that corresponds to the
module prefix.
In the past, it was often necessary, on very large scale applications,
for
different development teams to fight over the one-and-only copy of
struts-config.xml. Now, each module can be developed independently --
and
you can choose whether or not to combine them into a single webapp based
on whether or not you need to share session information between modules.
It's a very powerful paradigm.
Try it, you'll like it :-).
> Thinh
>
Craig
--
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>