struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "julio" <ju...@softsite.com.br>
Subject RES: sub-app switch
Date Fri, 06 Sep 2002 18:19:05 GMT
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 <tdoan@twjconsulting.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>,
>      tdoan@twjconsulting.com
> To: Struts Users Mailing List <struts-user@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:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>




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


Mime
View raw message