You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Tim W Wilson <tw...@us.ibm.com> on 2001/11/14 19:49:47 UTC
Multiple controller servlets
I would like some feedback on the subject of multiple controller servlets.
I have seen some of the previous discussion in the archives. The basic
problem has to do with modularity - both in the runtime and at development
time. The current solution of multiple config files certainly solves the
many of the development issues esp. that of managing a single large config
file, but what about other resources (messages). When I first started
using struts my first impulse to deal with modularity was to have multiple
controllers and I was quite surprised that I could not do this. The idea
of multiple controllers each self contained seemed quite natural. I have
since developed a patch that works quite well. But before a submit it I
would like to know:
Does anyone think this is a bad idea or that the current solution is
complete enough?
Is there a problem with the basic design as detailed below:
The basic problem in the current code is that the ActionServlet stores some
attributes in the ServletContext; other servlets overwrite these attrs.
The solution is to have one ActionServletContext per deployed action
servlet. This context is stored in the ServletContext under a unique key
for each controller. Those attrs that were stored in ServletContext are
stored instead in this "local" context.
A particular context becomes "active" at request handling time. The first
thing the action servlet does is to put its local context into the request
object using a statically defined key (Action.CURRENT_CONTEXT_KEY). Thus
the other part of this patch is updating the access to the application
scope attributes. These mostly reside in the taglibs (though I bet someone
accesses them in their Action class impls). The patch was to create helper
methods in RequestUtils that returned these atttrs directly (ex.
RequestUtils.getActionForwards()). These helper methods then access the
attrs out of the local context in the request using the original keys (ex.
Action.ACTION_FORWARDS).
Now clearly there are times when the active context in the request is not
appropriate:
- Welcome pages that were not served by a controller, hence there is no
active context stored in the request.
- Forwarding to jsps that are not part of the "module" - like back to a
welcome page.
I handled the first problem by having a "primary=true" initparm for a
particular action servlet. What this means is that the local context attrs
for this servlet are dumped into the global ServletContext at init() time.
The RequestUtil helper methods understand to look in the global context if
no local context is found. This would also be done for message lookup (no
msg in locally defined resources, look in global resources).
The solution to the second problem seems to require programmer intervention
(not good): either he explicitly clears the local context out of the
request before forwarding to an "external" resource or uses a special
forward class that knows to do so. However, it can be argued that the
welcome page is the only page that one should even consider forwarding to
outside the context of a controller servlet; access to other jsps should
go through actions the have been configured with the "forward" attribute.
This way each "module" has complete control to all its resources.
Since I am new to Struts I am no doubt missing things here. Thankyou for
any comments.
Tim W Wilson
Eclipse WSED Architecture & Development
internet: tww@us.ibm.com
(919) 254-0029 (TL 444-0029)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multiple controller servlets
Posted by Ted Husted <hu...@apache.org>.
martin.cooper@tumbleweed.com wrote:
> The subdirectory idea is one of the ideas I'm working through, although in
> a slightly different form from what you describe. For example, one idea
> would be to have a directory that contains all the Struts config files for
> each plugin. I like this much better than the proposed scheme of
> comma-separated file names in the Struts config file, because now my
> installer only needs to drop a new config file in the right directory, and
> it will be picked up and parsed automagically. Even better, my uninstaller
> only has to delete that file, rather than modify a file that another
> installer may have modified since its corresponding install.
That's sounds exactly like what I ~meant~ ;-)
What this becomes is a strategy for deploying Struts applications as
"portlets". The current design brings us within a hairs-breadth of this,
we just have to work around some relatively minor configuration issues
and adopt a few development conventions.
So, we point the digester at some folder, like WEB-INF/struts-config/*,
and have it parse whatever is there?
Or, do we need Servlet 2.3 for that?
> Right. And I'd like to go one step further, if possible, and find a way to
> do this without even having to modify the original Struts config file for
> the overall app.
Perhaps it should be a two-step process. First the configuration is
digested, and then merged with any other configuration already loaded.
This way we don't have to dance around the XML validation. It would also
give us a place to scan for any conflicts.
> If we modify the DTD, we might also want to think about moving some of the
> init-param entries into the config file. Since we would be freed from the
> restrictions of the web.xml DTD at that point, we'd have more flexibility
> to do things like adding multi-valued parameters. For example, you might be
> able to specify multiple resource file names as separate value elements for
> the same parameter name, again getting rid of the need for comma-separated
> values.
Allowing init-param's in the config is a fine idea.
But what I was thinking (above) is that each "sub-directory" could have
its own resource file, and that it would prefix each token with the
directory name, as the ActionMappings would also be prefixed, to avoid
collissions. The resources and other other configurations (like
validation.xml) are tightly coupled, and should be considered part of a
greater whole.
> -- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multiple controller servlets
Posted by ma...@tumbleweed.com.
At 06:58 AM 11/15/01, Ted Husted wrote:
> > Of course, I fully expect to see responses saying "both". ;-) I guess my
> > question is, what is the real problem people need to solve?
>
>+ Team development
>+ General manageablitity
>+ Distribution of plug-and-play Struts "application-lets"
>
>What this amounts to, I think, is that we need the ability to configure
>an application into several "packages" or "modules".
I agree, and I claim that the way to handle resources in this case is to
have each package or module use its own resource bundle. That solves all
three of the points you make above. The missing link, then, would be a way
of having them be loaded automagically.
In my view, this makes more sense than trying to merge multiple resource
files into one default bundle at run time. In that situation, there are
issues of potential conflicts between the files, amongst other things.
>If we continue to eliminate restrictions, so that we can have multiple
>
>+ Struts configurations
>+ Application Resources
>+ Action prefixes/suffixes
>+ ActionServlet services/extensions
>
>it all falls into place.
>
>So, a "package" could be setup under its own subdirectory,
>with its own Struts config and set of Application Resources, and
>incorporated by reference from the (single) ActionServlet config.
This is almost exactly the problem I am trying to solve right now in my
"day job". I'm in the process of designing a common framework, which
includes a base UI, which other product specific components plug into. I
need the whole thing to be dynamic, and I want to avoid having an installer
which knows how to modify XML files.
The subdirectory idea is one of the ideas I'm working through, although in
a slightly different form from what you describe. For example, one idea
would be to have a directory that contains all the Struts config files for
each plugin. I like this much better than the proposed scheme of
comma-separated file names in the Struts config file, because now my
installer only needs to drop a new config file in the right directory, and
it will be picked up and parsed automagically. Even better, my uninstaller
only has to delete that file, rather than modify a file that another
installer may have modified since its corresponding install.
>This *may* mean changes to a package's Struts config, if someone else
>was
>already using a given package name, but if the package is designed
>correctly,
>that should be it. No code or JSP changes. (The Struts config is really
>*so*
>cool.)
Right. And I'd like to go one step further, if possible, and find a way to
do this without even having to modify the original Struts config file for
the overall app.
>I'd also like to be able to drop the whole /do/ and *.do thing, and just
>be
>able to register the prefix for each package, so the command line would
>look
>like
>
>/module1/Action
>/module2/Action
>
>instead of
>
>/do/module1/Action
>/do/module2/Action
>
>To do this right, would also mean changes to the Struts DTD
>(as already discussed), so that there could be multiple
><struts-config> blocks, along with blocks for service
>extensions (validator/tile mappings, object factories, et cetera).
If we modify the DTD, we might also want to think about moving some of the
init-param entries into the config file. Since we would be freed from the
restrictions of the web.xml DTD at that point, we'd have more flexibility
to do things like adding multi-valued parameters. For example, you might be
able to specify multiple resource file names as separate value elements for
the same parameter name, again getting rid of the need for comma-separated
values.
>-T.
--
Martin Cooper
>martin.cooper@tumbleweed.com wrote:
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: "Struts Developers List" <st...@jakarta.apache.org>
> > Sent: Wednesday, November 14, 2001 2:18 PM
> > Subject: Re: Multiple controller servlets
> >
> > > A fix for multiple struts-config has come along first, but the need for
> > > multiple resource files is just as great.
> >
> > Multiple resource files can be used today, as long as you use a different
> > bundle name for each set of resources. This works well when you have
> > multiple components (or modules), each having their own set of resources.
> >
> > The question then becomes which functionality people consider to be
> missing:
> >
> > a) Loading multiple resource files and handling them all as if they were
> > part of the same default resource bundle.
> >
> > or
> >
> > b) Loading multiple resource files, each into its own bundle,
> > "automagically" - that is, without having to add your own initialization
> > code.
> >
>
> >
> > --
> > Martin Cooper
> >
> > > Once both of these features are added, I believe the use-cases I've seen
> > > would be addressed.
> > >
> > > The downside of multiple servlets is
> > >
> > > 1) Since servlets are multi-threaded, there is no performance advantage
> > > to having more than one.
> > >
> > > 2) If for any reason the servlets wanted to use the same utility Action,
> > > each would have to load its own copy.
> > >
> > > 3) Given multiple configs and resources, most applications would
> > > otherwise want all their servlets configured the same way, which means
> > > the desired configuration in web.xml have to be replicated.
> > >
> > > Two use-cases of my own are:
> > >
> > > 1) Multiple prefix/extension mappings. I tend to design my applications
> > > around "packages", each of which have their own "directory". If I could
> > > register the root of each package as Action mapping, then I wouldn't
> > > have to use /do/ or *.do at all. But that's really another configuration
> > > issue, where the servlet can accept multiple masks.
> > >
> > > 2) Multiple subclassed servlets to handle different services. The only
> > > good way to add services to the controller now is to subclass it. One
> > > way to avoid inheritance problems would be to have different subclasses
> > > available. But, this would really be better solved by Oledg's
> > > ServiceFactory.
> > >
> > > This isn't to say that I'm against multiple ActionServlets, just that we
> > > should be sure they are used to solve the right problems, and not used
> > > to mask problems with configuring a single ActionServlet.
> > >
> > > Offhand, the only thing that occurs to me about the strategy outlined
> > > would be the idea of keeping the multiple ActinServlet Configurations
> > > together in a Collection stored in the Servlet/ApplicationContext, and
> > > then passing around a key to that collection in the request. The helpers
> > > could then use the key to retrieve the configuration from the
> > > Collection.
> > >
> > > -Ted.
> > >
> > > Tim W Wilson wrote:
> > > >
> > > > I would like some feedback on the subject of multiple controller
> > servlets.
> > > > I have seen some of the previous discussion in the archives. The
> basic
> > > > problem has to do with modularity - both in the runtime and at
> > development
> > > > time. The current solution of multiple config files certainly solves
> > the
> > > > many of the development issues esp. that of managing a single large
> > config
> > > > file, but what about other resources (messages). When I first started
> > > > using struts my first impulse to deal with modularity was to have
> > multiple
> > > > controllers and I was quite surprised that I could not do this. The
> > idea
> > > > of multiple controllers each self contained seemed quite natural. I
> > have
> > > > since developed a patch that works quite well. But before a submit
> it I
> > > > would like to know:
> > > > Does anyone think this is a bad idea or that the current solution is
> > > > complete enough?
> > > > Is there a problem with the basic design as detailed below:
> > > >
> > > > The basic problem in the current code is that the ActionServlet stores
> > some
> > > > attributes in the ServletContext; other servlets overwrite these attrs.
> > > > The solution is to have one ActionServletContext per deployed action
> > > > servlet. This context is stored in the ServletContext under a unique
> > key
> > > > for each controller. Those attrs that were stored in
> ServletContext are
> > > > stored instead in this "local" context.
> > > >
> > > > A particular context becomes "active" at request handling time. The
> > first
> > > > thing the action servlet does is to put its local context into the
> > request
> > > > object using a statically defined key (Action.CURRENT_CONTEXT_KEY).
> > Thus
> > > > the other part of this patch is updating the access to the application
> > > > scope attributes. These mostly reside in the taglibs (though I bet
> > someone
> > > > accesses them in their Action class impls). The patch was to create
> > helper
> > > > methods in RequestUtils that returned these atttrs directly (ex.
> > > > RequestUtils.getActionForwards()). These helper methods then
> access the
> > > > attrs out of the local context in the request using the original keys
> > (ex.
> > > > Action.ACTION_FORWARDS).
> > > >
> > > > Now clearly there are times when the active context in the request is
> > not
> > > > appropriate:
> > > > - Welcome pages that were not served by a controller, hence there is no
> > > > active context stored in the request.
> > > > - Forwarding to jsps that are not part of the "module" - like back to a
> > > > welcome page.
> > > >
> > > > I handled the first problem by having a "primary=true" initparm for a
> > > > particular action servlet. What this means is that the local context
> > attrs
> > > > for this servlet are dumped into the global ServletContext at init()
> > time.
> > > > The RequestUtil helper methods understand to look in the global context
> > if
> > > > no local context is found. This would also be done for message lookup
> > (no
> > > > msg in locally defined resources, look in global resources).
> > > >
> > > > The solution to the second problem seems to require programmer
> > intervention
> > > > (not good): either he explicitly clears the local context out of the
> > > > request before forwarding to an "external" resource or uses a special
> > > > forward class that knows to do so. However, it can be argued
> that the
> > > > welcome page is the only page that one should even consider forwarding
> > to
> > > > outside the context of a controller servlet; access to other jsps
> > should
> > > > go through actions the have been configured with the "forward"
> > attribute.
> > > > This way each "module" has complete control to all its resources.
> > > >
> > > > Since I am new to Struts I am no doubt missing things here. Thankyou
> > for
> > > > any comments.
> > > >
> > > > Tim W Wilson
> > > > Eclipse WSED Architecture & Development
> > > > internet: tww@us.ibm.com
> > > > (919) 254-0029 (TL 444-0029)
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multiple controller servlets
Posted by Ted Husted <hu...@apache.org>.
> Of course, I fully expect to see responses saying "both". ;-) I guess my
> question is, what is the real problem people need to solve?
+ Team development
+ General manageablitity
+ Distribution of plug-and-play Struts "application-lets"
What this amounts to, I think, is that we need the ability to configure
an application into several "packages" or "modules".
If we continue to eliminate restrictions, so that we can have multiple
+ Struts configurations
+ Application Resources
+ Action prefixes/suffixes
+ ActionServlet services/extensions
it all falls into place.
So, a "package" could be setup under its own subdirectory,
with its own Struts config and set of Application Resources, and
incorporated by reference from the (single) ActionServlet config.
This *may* mean changes to a package's Struts config, if someone else
was
already using a given package name, but if the package is designed
correctly,
that should be it. No code or JSP changes. (The Struts config is really
*so*
cool.)
I'd also like to be able to drop the whole /do/ and *.do thing, and just
be
able to register the prefix for each package, so the command line would
look
like
/module1/Action
/module2/Action
instead of
/do/module1/Action
/do/module2/Action
To do this right, would also mean changes to the Struts DTD
(as already discussed), so that there could be multiple
<struts-config> blocks, along with blocks for service
extensions (validator/tile mappings, object factories, et cetera).
-T.
martin.cooper@tumbleweed.com wrote:
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> Sent: Wednesday, November 14, 2001 2:18 PM
> Subject: Re: Multiple controller servlets
>
> > A fix for multiple struts-config has come along first, but the need for
> > multiple resource files is just as great.
>
> Multiple resource files can be used today, as long as you use a different
> bundle name for each set of resources. This works well when you have
> multiple components (or modules), each having their own set of resources.
>
> The question then becomes which functionality people consider to be missing:
>
> a) Loading multiple resource files and handling them all as if they were
> part of the same default resource bundle.
>
> or
>
> b) Loading multiple resource files, each into its own bundle,
> "automagically" - that is, without having to add your own initialization
> code.
>
>
> --
> Martin Cooper
>
> > Once both of these features are added, I believe the use-cases I've seen
> > would be addressed.
> >
> > The downside of multiple servlets is
> >
> > 1) Since servlets are multi-threaded, there is no performance advantage
> > to having more than one.
> >
> > 2) If for any reason the servlets wanted to use the same utility Action,
> > each would have to load its own copy.
> >
> > 3) Given multiple configs and resources, most applications would
> > otherwise want all their servlets configured the same way, which means
> > the desired configuration in web.xml have to be replicated.
> >
> > Two use-cases of my own are:
> >
> > 1) Multiple prefix/extension mappings. I tend to design my applications
> > around "packages", each of which have their own "directory". If I could
> > register the root of each package as Action mapping, then I wouldn't
> > have to use /do/ or *.do at all. But that's really another configuration
> > issue, where the servlet can accept multiple masks.
> >
> > 2) Multiple subclassed servlets to handle different services. The only
> > good way to add services to the controller now is to subclass it. One
> > way to avoid inheritance problems would be to have different subclasses
> > available. But, this would really be better solved by Oledg's
> > ServiceFactory.
> >
> > This isn't to say that I'm against multiple ActionServlets, just that we
> > should be sure they are used to solve the right problems, and not used
> > to mask problems with configuring a single ActionServlet.
> >
> > Offhand, the only thing that occurs to me about the strategy outlined
> > would be the idea of keeping the multiple ActinServlet Configurations
> > together in a Collection stored in the Servlet/ApplicationContext, and
> > then passing around a key to that collection in the request. The helpers
> > could then use the key to retrieve the configuration from the
> > Collection.
> >
> > -Ted.
> >
> > Tim W Wilson wrote:
> > >
> > > I would like some feedback on the subject of multiple controller
> servlets.
> > > I have seen some of the previous discussion in the archives. The basic
> > > problem has to do with modularity - both in the runtime and at
> development
> > > time. The current solution of multiple config files certainly solves
> the
> > > many of the development issues esp. that of managing a single large
> config
> > > file, but what about other resources (messages). When I first started
> > > using struts my first impulse to deal with modularity was to have
> multiple
> > > controllers and I was quite surprised that I could not do this. The
> idea
> > > of multiple controllers each self contained seemed quite natural. I
> have
> > > since developed a patch that works quite well. But before a submit it I
> > > would like to know:
> > > Does anyone think this is a bad idea or that the current solution is
> > > complete enough?
> > > Is there a problem with the basic design as detailed below:
> > >
> > > The basic problem in the current code is that the ActionServlet stores
> some
> > > attributes in the ServletContext; other servlets overwrite these attrs.
> > > The solution is to have one ActionServletContext per deployed action
> > > servlet. This context is stored in the ServletContext under a unique
> key
> > > for each controller. Those attrs that were stored in ServletContext are
> > > stored instead in this "local" context.
> > >
> > > A particular context becomes "active" at request handling time. The
> first
> > > thing the action servlet does is to put its local context into the
> request
> > > object using a statically defined key (Action.CURRENT_CONTEXT_KEY).
> Thus
> > > the other part of this patch is updating the access to the application
> > > scope attributes. These mostly reside in the taglibs (though I bet
> someone
> > > accesses them in their Action class impls). The patch was to create
> helper
> > > methods in RequestUtils that returned these atttrs directly (ex.
> > > RequestUtils.getActionForwards()). These helper methods then access the
> > > attrs out of the local context in the request using the original keys
> (ex.
> > > Action.ACTION_FORWARDS).
> > >
> > > Now clearly there are times when the active context in the request is
> not
> > > appropriate:
> > > - Welcome pages that were not served by a controller, hence there is no
> > > active context stored in the request.
> > > - Forwarding to jsps that are not part of the "module" - like back to a
> > > welcome page.
> > >
> > > I handled the first problem by having a "primary=true" initparm for a
> > > particular action servlet. What this means is that the local context
> attrs
> > > for this servlet are dumped into the global ServletContext at init()
> time.
> > > The RequestUtil helper methods understand to look in the global context
> if
> > > no local context is found. This would also be done for message lookup
> (no
> > > msg in locally defined resources, look in global resources).
> > >
> > > The solution to the second problem seems to require programmer
> intervention
> > > (not good): either he explicitly clears the local context out of the
> > > request before forwarding to an "external" resource or uses a special
> > > forward class that knows to do so. However, it can be argued that the
> > > welcome page is the only page that one should even consider forwarding
> to
> > > outside the context of a controller servlet; access to other jsps
> should
> > > go through actions the have been configured with the "forward"
> attribute.
> > > This way each "module" has complete control to all its resources.
> > >
> > > Since I am new to Struts I am no doubt missing things here. Thankyou
> for
> > > any comments.
> > >
> > > Tim W Wilson
> > > Eclipse WSED Architecture & Development
> > > internet: tww@us.ibm.com
> > > (919) 254-0029 (TL 444-0029)
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multiple controller servlets
Posted by ma...@tumbleweed.com.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, November 14, 2001 2:18 PM
Subject: Re: Multiple controller servlets
> A fix for multiple struts-config has come along first, but the need for
> multiple resource files is just as great.
Multiple resource files can be used today, as long as you use a different
bundle name for each set of resources. This works well when you have
multiple components (or modules), each having their own set of resources.
The question then becomes which functionality people consider to be missing:
a) Loading multiple resource files and handling them all as if they were
part of the same default resource bundle.
or
b) Loading multiple resource files, each into its own bundle,
"automagically" - that is, without having to add your own initialization
code.
Of course, I fully expect to see responses saying "both". ;-) I guess my
question is, what is the real problem people need to solve?
--
Martin Cooper
> Once both of these features are added, I believe the use-cases I've seen
> would be addressed.
>
> The downside of multiple servlets is
>
> 1) Since servlets are multi-threaded, there is no performance advantage
> to having more than one.
>
> 2) If for any reason the servlets wanted to use the same utility Action,
> each would have to load its own copy.
>
> 3) Given multiple configs and resources, most applications would
> otherwise want all their servlets configured the same way, which means
> the desired configuration in web.xml have to be replicated.
>
> Two use-cases of my own are:
>
> 1) Multiple prefix/extension mappings. I tend to design my applications
> around "packages", each of which have their own "directory". If I could
> register the root of each package as Action mapping, then I wouldn't
> have to use /do/ or *.do at all. But that's really another configuration
> issue, where the servlet can accept multiple masks.
>
> 2) Multiple subclassed servlets to handle different services. The only
> good way to add services to the controller now is to subclass it. One
> way to avoid inheritance problems would be to have different subclasses
> available. But, this would really be better solved by Oledg's
> ServiceFactory.
>
> This isn't to say that I'm against multiple ActionServlets, just that we
> should be sure they are used to solve the right problems, and not used
> to mask problems with configuring a single ActionServlet.
>
> Offhand, the only thing that occurs to me about the strategy outlined
> would be the idea of keeping the multiple ActinServlet Configurations
> together in a Collection stored in the Servlet/ApplicationContext, and
> then passing around a key to that collection in the request. The helpers
> could then use the key to retrieve the configuration from the
> Collection.
>
> -Ted.
>
> Tim W Wilson wrote:
> >
> > I would like some feedback on the subject of multiple controller
servlets.
> > I have seen some of the previous discussion in the archives. The basic
> > problem has to do with modularity - both in the runtime and at
development
> > time. The current solution of multiple config files certainly solves
the
> > many of the development issues esp. that of managing a single large
config
> > file, but what about other resources (messages). When I first started
> > using struts my first impulse to deal with modularity was to have
multiple
> > controllers and I was quite surprised that I could not do this. The
idea
> > of multiple controllers each self contained seemed quite natural. I
have
> > since developed a patch that works quite well. But before a submit it I
> > would like to know:
> > Does anyone think this is a bad idea or that the current solution is
> > complete enough?
> > Is there a problem with the basic design as detailed below:
> >
> > The basic problem in the current code is that the ActionServlet stores
some
> > attributes in the ServletContext; other servlets overwrite these attrs.
> > The solution is to have one ActionServletContext per deployed action
> > servlet. This context is stored in the ServletContext under a unique
key
> > for each controller. Those attrs that were stored in ServletContext are
> > stored instead in this "local" context.
> >
> > A particular context becomes "active" at request handling time. The
first
> > thing the action servlet does is to put its local context into the
request
> > object using a statically defined key (Action.CURRENT_CONTEXT_KEY).
Thus
> > the other part of this patch is updating the access to the application
> > scope attributes. These mostly reside in the taglibs (though I bet
someone
> > accesses them in their Action class impls). The patch was to create
helper
> > methods in RequestUtils that returned these atttrs directly (ex.
> > RequestUtils.getActionForwards()). These helper methods then access the
> > attrs out of the local context in the request using the original keys
(ex.
> > Action.ACTION_FORWARDS).
> >
> > Now clearly there are times when the active context in the request is
not
> > appropriate:
> > - Welcome pages that were not served by a controller, hence there is no
> > active context stored in the request.
> > - Forwarding to jsps that are not part of the "module" - like back to a
> > welcome page.
> >
> > I handled the first problem by having a "primary=true" initparm for a
> > particular action servlet. What this means is that the local context
attrs
> > for this servlet are dumped into the global ServletContext at init()
time.
> > The RequestUtil helper methods understand to look in the global context
if
> > no local context is found. This would also be done for message lookup
(no
> > msg in locally defined resources, look in global resources).
> >
> > The solution to the second problem seems to require programmer
intervention
> > (not good): either he explicitly clears the local context out of the
> > request before forwarding to an "external" resource or uses a special
> > forward class that knows to do so. However, it can be argued that the
> > welcome page is the only page that one should even consider forwarding
to
> > outside the context of a controller servlet; access to other jsps
should
> > go through actions the have been configured with the "forward"
attribute.
> > This way each "module" has complete control to all its resources.
> >
> > Since I am new to Struts I am no doubt missing things here. Thankyou
for
> > any comments.
> >
> > Tim W Wilson
> > Eclipse WSED Architecture & Development
> > internet: tww@us.ibm.com
> > (919) 254-0029 (TL 444-0029)
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multiple controller servlets
Posted by Ted Husted <hu...@apache.org>.
A fix for multiple struts-config has come along first, but the need for
multiple resource files is just as great.
Once both of these features are added, I believe the use-cases I've seen
would be addressed.
The downside of multiple servlets is
1) Since servlets are multi-threaded, there is no performance advantage
to having more than one.
2) If for any reason the servlets wanted to use the same utility Action,
each would have to load its own copy.
3) Given multiple configs and resources, most applications would
otherwise want all their servlets configured the same way, which means
the desired configuration in web.xml have to be replicated.
Two use-cases of my own are:
1) Multiple prefix/extension mappings. I tend to design my applications
around "packages", each of which have their own "directory". If I could
register the root of each package as Action mapping, then I wouldn't
have to use /do/ or *.do at all. But that's really another configuration
issue, where the servlet can accept multiple masks.
2) Multiple subclassed servlets to handle different services. The only
good way to add services to the controller now is to subclass it. One
way to avoid inheritance problems would be to have different subclasses
available. But, this would really be better solved by Oledg's
ServiceFactory.
This isn't to say that I'm against multiple ActionServlets, just that we
should be sure they are used to solve the right problems, and not used
to mask problems with configuring a single ActionServlet.
Offhand, the only thing that occurs to me about the strategy outlined
would be the idea of keeping the multiple ActinServlet Configurations
together in a Collection stored in the Servlet/ApplicationContext, and
then passing around a key to that collection in the request. The helpers
could then use the key to retrieve the configuration from the
Collection.
-Ted.
Tim W Wilson wrote:
>
> I would like some feedback on the subject of multiple controller servlets.
> I have seen some of the previous discussion in the archives. The basic
> problem has to do with modularity - both in the runtime and at development
> time. The current solution of multiple config files certainly solves the
> many of the development issues esp. that of managing a single large config
> file, but what about other resources (messages). When I first started
> using struts my first impulse to deal with modularity was to have multiple
> controllers and I was quite surprised that I could not do this. The idea
> of multiple controllers each self contained seemed quite natural. I have
> since developed a patch that works quite well. But before a submit it I
> would like to know:
> Does anyone think this is a bad idea or that the current solution is
> complete enough?
> Is there a problem with the basic design as detailed below:
>
> The basic problem in the current code is that the ActionServlet stores some
> attributes in the ServletContext; other servlets overwrite these attrs.
> The solution is to have one ActionServletContext per deployed action
> servlet. This context is stored in the ServletContext under a unique key
> for each controller. Those attrs that were stored in ServletContext are
> stored instead in this "local" context.
>
> A particular context becomes "active" at request handling time. The first
> thing the action servlet does is to put its local context into the request
> object using a statically defined key (Action.CURRENT_CONTEXT_KEY). Thus
> the other part of this patch is updating the access to the application
> scope attributes. These mostly reside in the taglibs (though I bet someone
> accesses them in their Action class impls). The patch was to create helper
> methods in RequestUtils that returned these atttrs directly (ex.
> RequestUtils.getActionForwards()). These helper methods then access the
> attrs out of the local context in the request using the original keys (ex.
> Action.ACTION_FORWARDS).
>
> Now clearly there are times when the active context in the request is not
> appropriate:
> - Welcome pages that were not served by a controller, hence there is no
> active context stored in the request.
> - Forwarding to jsps that are not part of the "module" - like back to a
> welcome page.
>
> I handled the first problem by having a "primary=true" initparm for a
> particular action servlet. What this means is that the local context attrs
> for this servlet are dumped into the global ServletContext at init() time.
> The RequestUtil helper methods understand to look in the global context if
> no local context is found. This would also be done for message lookup (no
> msg in locally defined resources, look in global resources).
>
> The solution to the second problem seems to require programmer intervention
> (not good): either he explicitly clears the local context out of the
> request before forwarding to an "external" resource or uses a special
> forward class that knows to do so. However, it can be argued that the
> welcome page is the only page that one should even consider forwarding to
> outside the context of a controller servlet; access to other jsps should
> go through actions the have been configured with the "forward" attribute.
> This way each "module" has complete control to all its resources.
>
> Since I am new to Struts I am no doubt missing things here. Thankyou for
> any comments.
>
> Tim W Wilson
> Eclipse WSED Architecture & Development
> internet: tww@us.ibm.com
> (919) 254-0029 (TL 444-0029)
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>