"Craig R. McClanahan" wrote:
>
> "Sukachevin, Stoehr" wrote:
>
> > In looking at some of the more recent source code for v1.0, it appears that
> > since the ActionServlet caches a lot of objects in the servlet context, like
> > action mappings, app resources, etc., the ActionServlet was not designed to
> > allow multiple instances of the servlet to be deployed in a single web
> > application.
> >
> > In other words, if for whatever reason, one wanted to deploy multiple
> > ActionServlets in a single web application so that each servlet can deal
> > with its own set of action mappings, etc., this would not work with the
> > current implementation of the ActionServlet.
> >
> > Is my understanding correct?
> >
>
> That is correct. Within the context of a single web application, the design
> assumption is (and, at least as far as intent goes) always has been, that there
> will be exactly one instance of the controller servlet. Separate web apps, of
> course, are completely independent of each other, and will have their own custom
> configured instances.
>
> Because this question comes up occasionally, I would be interested in
> understanding more about what might motivate a desire to have more than one
> instance of the controller servlet. Do you have some particular use cases in
> mind where this would be helpful?
>
I'll take a stab at this...I've been meaning to for a while but
have been too busy to sit down and write up my issues.
First off, I'll mention that this single controller issue
is actually a stopper in my current struts based project. My day
job is for a financial institution. We're currently prototyping the
move of our web based commercial cash management suite
offering from ASP to JSP [hopefully] based on struts.
The site is a portal like collection of sub-applications
which share a common integrated signon, environment,
and "shell" framework. Currently, we have around 7
production sub-applications providing a range of services with
several more in active development.
Each sub-app is logically independent from the others and is usually
developed/maintained by different groups. They must work and play
well together but cannot be developed, configured, or deployed in
a monolithic fashion.
(Reference a prior mailing on the struts user list that I wrote up
in early January detailing my site's macro structure:
<
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01823.html
>
)
Because the sub-apps must cooperate and share certain common
components including sign-on in the application and session contexts,
they _cannot_ be deployed as different webapps. Because of the
number and size of the logically and functionally independent sub-apps,
they should be developed/deployed as separate controllers (which may
have
unique customizations required to support the peculiarities of the
particular sub-app).
As an application framework, struts should strive to minimize the
amount and type of restrictions placed on the apps using it. Forcing
deployment assumptions such as one controller servlet per webapp
oversteps the bounds of what the framework should do. Yes, some
application designs are not really affected by the one controller
restriction, but, some apps are not all apps.
(I've pasted quotes from previous emails on this subject below so
that I can respond in context.)
> The reasoning is that some resources are truly application wide,
> and there is zero benefit in duplicating them.
> For example,
> because servlets run in a multithreaded environment, having more
> instances of them would not make it run any faster.
This point I don't dispute (except for the 'zero benefit' part :).
Speed isn't necessarily the issue -- the issue is logical
organization for development, maintenance, and production support.
I don't really dispute the above statements, but
I also don't think that having multiple controllers contradicts them
either. Multiple controllers should be able to coexist non-
destructively.
>
> Also, a single controller servlet gives you a central point of
> control where you can guarantee that functions you want
> performed happen on every single request.
Regardless of whether you're running a single controller or
multiple ones, they're running off the same code base so these
"certain" functions will happen anyway -- just not in one specific
monolithic object.
> If you have more than one instance of ActionServlet (even if it is subclassed)
> in the same webapp, you will run into problems if you depend on any of the
> [below] -- which is almost impossible to avoid in a Struts based application.
> For example, the only mappings that will be visible are those loaded from the
> last struts-config.xml file that was processed, because the ActionMappings
> collection is a global variable per webapp.
>
I realize that it may actually be somewhat difficult at this point
to abstract struts to allow multiple controllers in a webapp --
quite a few custom tags rely on it and already developed struts
applications may be making making use of and depend on the
keys and structures used to store the global servlet context
resources. Maybe if these servlet context attributes are managed
more cooperatively (with the assumption that multiple controllers
can access/initialize them)...Perhaps giving each controller a
unique app ID which it can use in accessing/identifying its own
resources (this is actually what I did in my prototype for my custom
resources)
> The controller servlet initializes the following servlet context attributes,
> under the keys identified in square brackets:
>
> * The generic DataSource object if you have initialized one
> under the default key. [org.apache.struts.action.DATA_SOURCE]
I cannot, unfortunately, provide any commentary (besides this dodge :)
on the generic DataSource since I have in no way used it or needed
it in my development work.
>
> * The ActionFormBeans collection that is the lookup table for everything
> configured in the <form-beans> section of your struts-config.xml file.
> [org.apache.struts.action.FORM_BEANS]
I see no reason why this collection can't be shared among multiple
controllers. The first one [controller] to initialize creates the
collection -- the remaining controllers perhaps just add to it. The
real problem at this point is sub-application namespace collisions
with respect to the names given to the form beans. This namespace
conflict can be resolved by using some variety of the controller unique
app ID mentioned above to qualify the names.
>
> * The ActionForwards collection that is the lookup table for everything
> configured in the <global-forwards> section of your struts-config.xml file.
> [org.apache.struts.action.FORWARDS]
Ditto for this collection. Since they are "global forwards", maybe no
special care needs to be taken related to namespace collisions. They
should be, as you say, global and accessible to all controllers. Then
again, some sort of namespace qualification may be needed anyway.
>
> * The ActionMappings collection that is the lookup table for everything
> configured in the <action-mappings> section of your struts-config.xml file.
> [org.apache.struts.action.MAPPINGS]
And now we come to marrow of the problem -- the action mappings.
I do think that multiple controllers can cooperate here by
qualifying their mappings through the app ID concept described above.
This is certainly a solvable problem.
>
> * The MessageResources implementation for your application
> resources object. [org.apache.struts.action.MESSAGE]
And again here. I can see where having a central message resources
repository may be convenient for some, but what if that repository
actually spans 10 very different sub-applications and becomes so
large as such that it is unwieldy to maintain. Not to mention the
configuration nightmare of keeping it up to date in production with
changes coming from all angles. Best to split it apart along sub-app
lines. Let the developers/maintainers of the individual sub-apps
be responsible for their messages and their messages alone -- no
cross talk, no conflict.
-------------
I hope I've been able to present my concerns and arguments in
at least a partially understandable way. I am open to discussion
on this, but unfortunately, I feel at this time that the end result
should be that struts not impose the ONE controller solution on us.
Although others may disagree, I cannot say that struts 1.0 is
ready for final release until the single-controller limitation is
removed. Removing the limitation *may* require some changes that
are not backward compatible and therefore should be made sooner
rather than later.
e
--
_______________________________________________________________________
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
