struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Design Discussion] Multiple Controllers Per Web App
Date Mon, 07 Jan 2002 17:26:49 GMT
On Sun, 6 Jan 2002, John Yu wrote:

> Date: Sun, 06 Jan 2002 23:09:10 +0800
> From: John Yu <>
> Reply-To: Struts Developers List <>
> To: Struts Developers List <>
> Subject: Re: [Design Discussion] Multiple Controllers Per Web App
> I have followed this thread for some time. I can finally collect some of my
> thoughts after the effect of all the New Year wines and champagnes have
> eventually died away. ;-)
> This (multi-controller idea) definitely looks exciting and promising. It
> should solve the team development management issue most of us are currently
> facing.
> However, let me play devil's advocate. I have these observations:
> Stepping back and pondering on the proposed architecture, I can see it
> resembles the Servlet architecture: Multiple loadable "apps", context
> paths, default/root app, ActionServlet looks like a web container, Action
> looks like a servlet, struts-config.xml looks like web.xml...
> The way I see it, to provide a proper, comprehensive and complete solution
> (a framework), one will end up with something like, as observed by Ted,
> Jetspeed or Websphere which overlaps significantly with the Servlet spec.
> (Remark: I don't have much experience with either software.) With the
> proposal, I can see Struts TNG is going down that path.
> Let's put aside practicality. In an ideal world, does it make more sense if
> the Struts architecture *is* the Servlet architecture and vice versa?
> Should all the MVC mechanisms introduced by Struts be part of the Servlet
> spec? Could Servlet 3.0 (or whatever version) absorb Struts?
> Sorry that this is a far cry from the original intention of the discussion.
> But I feel a bit unsure and uneasy seeing that we're building a
> partitioning framework on the top of an existing partitioning framework
> with significant duplications...

For what it's worth, I'm not planning on integrating any "reloadable
sub-application" functionality into Struts for this.  Besides the
philosophical issue you raise (it's really the container's job to do that
sort of thing), it is not technically possible to write code for this that
would run under the security manager policies of any J2EE server, because
none of them will allow you to create and use your own class loader.

Instead, my focus is on allowing you to define and use multiple
"sub-applications", each with its own struts-config.xml file (and
associated other stuff, like message resources), in the same web
application -- with *maximum* emphasis on backwards compatibility for
existing user applications.  I've got an implementation of this about
three quarters done -- you'll see discussion of it shortly.

> --
> John Yu                       Scioworks Technologies

Craig McClanahan

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

View raw message