Re: Is ActionMappings shared by all the servlets ?

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 4 Jul 2002 olschmeltzer@airfrance.fr wrote:

> Date: Thu, 4 Jul 2002 11:57:03 +0200
> From: olschmeltzer@airfrance.fr
> To: struts-user@jakarta.apache.org
> Cc: craigmcc@apache.org
> Subject: Re: Is ActionMappings shared by all the servlets ?
>
> Thank you very much for your answer. To make things clearer for me (sorry
> if I am being obtuse), I would like to ask you some more questions and
> advice.
>
> Does this mean that in my web.xml file, I can't have two servlets that
> are implemented by a ActionServlet instance (or one of its sub-classes)
> ?

The existing ActionServlet makes many assumptions that there is only one
controller servlet.  Just as one example, the ActionMappings collection is
stored under a single attribute key ("org.apache.struts.action.MAPPINGS").
That is why you got the behavior that you observed -- the mappings for the
servlet that was initialized second simply replace the ones for the
servlet that was initialized first.  In order for two controllers to work,
this particular part of Struts (along with many similar ones) would need
to be changed.

Bottom line -- Struts was designed for a single controller servlet per web
application.  Fighting against this design is probably not a useful way to
spend your time  :-).

> In our web application, we have different sub-applications that have
> their own flow of events, JSP files, Actions and so on. I would have
> liked to map these business processes to different extensions
> (*.app1; *.app2, etc.), so that these applications are separated from
> one another, have different initialisations to
> do, can produce different log files, are managed independently,
> and could be executing separatly.
>
> If I understand well what you said, since I cannot do this in my web.xml
> file, the only way left is to do it inside the struts-config.xml file by
> mapping different actions to these different business processes : am I
> right ?

In Struts 1.0, you are right, unless you run your "sub-applications" as
independent web applications.  Unless they need to share sessions, this
would be my recommendation.

> Would it be not better, conceptually, to manage different
> servlets ?

No.  Additional servlets would just cause additional overhead and memory
occupancy, with no gain in performance.  The gain in maintainability comes
from separate struts-config.xml files, not from separate controller
servlets.

> Or do you think that Struts 1.1 has provided a good way to
> handle this through sub-applications (although there is still a single
> servlet running) ?

I'm quite biased :-), but yes -- I think this is the right answer.  It
accomplishes all of your goals of independence, but still allows the
sub-apps to interoperate with each other in the same session.

One architectural note -- subapps in 1.1 are based on using a path prefix
to separate the subapps.  The actions would all be mapped to a common
extension (like "*.do"), but the path tells you which subapp
("/admin/setupSomething.do" and "/catalog/setupSomething.do" can be
independent actions in the "/admin" and "/catalog" subapps).

> I understand the need for a unique controller
> managing the whole application, but what if you have different
> "applications" running on your web site ?
>  Would you advise
> on having them in different webapps ?

Yes.

> But then, what if they share code or want to communicate to one another
? The Struts predefined classes
> ForwardAction or
> IncludeAction are said to be used to call another servlet from a Struts application ; this servlet cannot then be implemented through the Struts
> framework, right ?
> Am I trying to use the Struts framework in a way it should not be used ?
> Thanks again for your help.
>

To share code, you can take advantage of the "shared repository"
capabilities provided by your container (such as the "/common/lib"
directory in Tomcat 4), although you are usually better off loading
everything you need into each webapp.  There are many subtle class loader
issues that you need to become aware of when code is shared.

To cross over between webapps, set up a <forward> that does a redirect,
and specify an absolute URL.

> Olivier
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>