You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Sukachevin, Stoehr" <st...@commerceone.com> on 2001/02/23 22:21:02 UTC
Multiple ActionServlet instances in a web app
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?
-- Stoehr
Re: Multiple ActionServlet instances in a web app
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Elod Horvath wrote:
> "Craig R. McClanahan" wrote:
> > 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.
>
Elod, thanks (as always) for your thoughtful and detailed analysis. I'm going to be
on an airplane a lot this week, so I'm going to spend a bunch of that time thinking on
these issues. My original vision was that you would deal with these kinds of
complexity and (functional) scale issues by using multiple cooperating webapps. Now,
I want to think about that a little more.
If I can define a non-backwards-incompatible way to implement multiple controllers
later (that we can all agree to), I'm game to go ahead with a 1.0 release now --
otherwise, this is definitely something that should be determined (one way or the
other) before a 1.0 final release.
In the mean time, I'm sure you've thought of a few of the following workarounds within
the current architecture, based on the idea of using separate webapps but establishing
a means of sharing stuff:
* Are you using container-managed security for login authentication?
If so, the container might have "single sign on" features that manage
the cross-app authentication questions.
* Most servlet containers (although not required by the spec) offer a means
to declare a set of classes to be "global" to all web apps. Normally, this
is done by establishing a classloader that is the (shared) parent of the
classloaders used for each web app. One nice feature of such global
classes is that global statics are shared -- so you can easily build an
infrastructure for in-memory sharing between webapps.
* Alternatively, it is also feasible to use external mechanisms (databases,
EJBs, etc.) to share information between webapps -- although there are
likely to be performance impacts if the amount of shared data is high,
and/or the rate of change to this data is high.
Craig
Re: Multiple ActionServlet instances in a web app
Posted by Michael Gerdau <mg...@technosis.de>.
>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.
Let me rephrase what I understood of ypur concerns to see wether I
got your focal point:
Your main issue is that you want to be able to build large modular
webapps with each sub-webapp being separately maintain-/develop-/deployable
rather than providing one large monolithic webapp.
Assuming my above rephrasing does correctly capture your concerns here
are my comments on it:
I agree with that requirement.
I also believe it should be possibly to achieve that using the current
design without too much additional hazzle.
How about the following quick and dirty idea:
Make all your separate sub-webapps independend webapps. Each of these
does need some "gate" to be entered from one of the other apps. Also
add "transition points" into your sub-webapps to act as stepping stones.
AFAICT you'll need such "gates" anyway since you have to define
interfaces between your sub-webapps even when allowing for different
controllers, set of action-mappings etc.
You may have to add a custom taglib like the 'app' taglib from the
example application to handle the transition but I believe it could
be done.
At a later point in time this may be further supported by struts
by allowing dynamically reloading the action-mapping of a webapp.
By means of this we could modularize action-mappings which might
help to achieve the above design goal.
Of course this is just a quick shot and very likely needs further
refinement. However it should help as a general idea.
>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.
I do disagree.
I do this mostly on the basis that I don't value the restrictions
you point out as being that important. After all your requirements
seem to be rather complex and way beyond what most current webapps
need (don't get me wrong - that doesn't make these requirements
invalid).
Second I'm not yet convinced your requirements can't be satiesfied
(to an acceptable degree) by the design as it is just now.
Third I do believe it just is about time to release a (basic)
framework that does solve most users needs to have a solid platform
to continue further development (i.e. toward 1.1, 1.2, ...2.0)
My thoughts, best,
Michael
--
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: mgd@technosis.de
Just say NO! to Microsoft Windows.
PGP-keys available on request or at public keyserver
Re: Multiple ActionServlet instances in a web app
Posted by Elod Horvath <el...@itfais.com>.
"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/)
Re: Multiple ActionServlet instances in a web app
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
"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?
>
> -- Stoehr
Craig McClanahan
RE: Multiple ActionServlet instances in a web app
Posted by Palamadai Sriram <pa...@s1.com>.
No, Configure your webs server to handle multiple instances of your
Controller servlet(ActionServlet) . Each instance will use its own xml file
where you can specify the mappings etc.
-----Original Message-----
From: Sukachevin, Stoehr [mailto:stoehr.sukachevin@commerceone.com]
Sent: Friday, February 23, 2001 4:21 PM
To: 'struts-dev@jakarta.apache.org'
Subject: Multiple ActionServlet instances in a web app
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?
-- Stoehr