struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Evans (JIRA)" <>
Subject [jira] Closed: (STR-86) Struts needs to cleanly support running multiple controllers within the context of a single webapp
Date Tue, 25 Apr 2006 03:06:10 GMT
     [ ]
David Evans closed STR-86:

    Resolution: Fixed

> Struts needs to cleanly support running multiple controllers within the context of a
single webapp
> --------------------------------------------------------------------------------------------------
>          Key: STR-86
>          URL:
>      Project: Struts Action 1
>         Type: Improvement

>   Components: Action
>     Versions: 1.0 Beta 1
>  Environment: Operating System: All
> Platform: All
>     Reporter: Elod Horvath
>     Assignee: Craig McClanahan
>     Priority: Minor
>      Fix For: 1.1 Family
>  Attachments: RE-Multiple-ActionServlet-instances-in-a-web-app.txt, package.html, requeststructure.gif,
response1.txt, solution1.txt
> (write-up snipped from struts-dev mailing list)
> -----------------------------------------------
> [Multi-controller support needed to implement] portal-like 
> collections of sub-applications 
> which share a common integrated signon, environment, 
> and "shell" framework.  
> 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.
> 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).
> separate WEBAPPs          == shared _nothing_
> one webapp/one controller == [large] monolithic shared _everything_
> 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.
> [all other application context resources stored under global keys must
>  also be taken into consideration]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message