You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2001/12/02 22:51:31 UTC
Re: Multiple controller servlets
Under the heading "A step in the right direction", how about if we
(meaning I) were to start with defining a simple "ActionResources" class
that encapsulated everything that is now available under a Action.*_KEY.
This comes down to:
public interface ActionResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
This could then be instantiated using the request
ActionResourcesBase shared = new ActionResourcesBase(request);
and passed in the request. .
We could then start refactoring things to look for this bean instead.
Initially ,it would mostly be looking things up under their key in the
context. But at some point, a different implementation of
ActionResources could get them from someplace else entirely.
Here's a question:
Does multiple ActionServlets mean multiple Actions?
Or should there still be one Action class implementation per
application, with all the ActionServlets drinking from the same well?
Do any multi-threading wizards out there have an opinion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2214
The code looks fine, but I'd be glad for a second on committing this.
(Developer votes welcome.)
-- 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 Andy Noble <an...@data-workshop.com>.
I should have learnt from school - "read the question!" - so I've had a
quick look at the source code.
I see now, having read a bit more, that you are performing the
locking/checking to see if the action class itself needs to be instantiated.
So at the moment, every time an action needs to be accessed, the code uses
the double check locking (DCL) to determine if the Action class needs to be
instantiated. But the DCL has been shown to be problematic. The new code in
bug 2214 attempts to solve this by performing a synchronised lazy
instantiation, which now involves 2 synchronisation steps that are not
conditional anymore.
I would have thought that this is going to create a performance issue as
this synchronisation will happen on every request now, won't it?
Would it not be more appropriate to scan struts-config at initialisation and
instantiate an instance of all the declared action classes? Then this would
obviate the need for any synchronisation when attempting to reference an
action object.
Now just let me look over the question again....
Andy
(BTW, I'm not a multi-threading wizard, just some smuck with a big keyboard)
----- Original Message -----
From: Andy Noble <an...@data-workshop.com>
To: Struts Developers List <st...@jakarta.apache.org>
Sent: Sunday, December 02, 2001 11:18 PM
Subject: Re: Multiple controller servlets
> >
> > Do any multi-threading wizards out there have an opinion on
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2214
> >
>
> At the moment, the 'getActionInstanceLock' method returns an object for
the
> action class to ensure that there is effectively one monitor (lock object)
> for each action class. However, this code has to be synchronised in case
the
> lock object doesn't exist and needs to be created.
>
> To avoid having to synchronize on the 'getActionInstanceLock' method,
would
> it not be better to have the Action class create an entry for itself into
> 'actionInstanceLocks' collection during the class initialisation? Or use
the
> action class object itself instead?
>
> Andy
>
>
> --
> 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 Andy Noble <an...@data-workshop.com>.
>
> Do any multi-threading wizards out there have an opinion on
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2214
>
At the moment, the 'getActionInstanceLock' method returns an object for the
action class to ensure that there is effectively one monitor (lock object)
for each action class. However, this code has to be synchronised in case the
lock object doesn't exist and needs to be created.
To avoid having to synchronize on the 'getActionInstanceLock' method, would
it not be better to have the Action class create an entry for itself into
'actionInstanceLocks' collection during the class initialisation? Or use the
action class object itself instead?
Andy
--
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>.
I had originally thought we might start posting an ActionResources
object in the request, so it would be there when we started to refactor
the tag extensions, and also for the use of other presentation systems
like Velocity templates. So, for a time, it would really be redundant,
and could just getting from the contexts things that other components
now get directly. But once the tag extensions were refactored to use it
instead, it would open the door for multiple ActionServlets, each
sending down their own instances of the ActionResources object.
I wouldn't change the setServlet methods at first, but add others that
used the other object. Then once everything is in place, the old methods
could be bypassed, deprecated, and eventually removed.
We have to be careful in this, since we don't know what other developers
are doing. So, we need to look for opportunities to deprecate a method
for a time, before removing it. We should really try to put a release
between any final changes to the API.
Donnie Hale wrote:
>
> Ted,
>
> The stepwise refinement sounds like a reasonable way to go. I've got a good
> chunk of one definite piece of that done - a "resource repository", which
> would implement most of your proposed interface (it has no knowledge of
> requests at present); and a "config handler", which reads servlet init
> parms, struts-config.xml, and web.xml and populates the resource repository.
>
> To make sure I'm on the same page, a reference to an object implementing
> your interface would be what's passed to the varions Action*.setServlet
> methods instead of the ActionServlet. To make sense, all those method names
> would need changed. Is that right?
>
> Any other input?
>
> Thanks,
>
> Donnie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multiple controller servlets
Posted by Donnie Hale <do...@haleonline.net>.
Ted,
The stepwise refinement sounds like a reasonable way to go. I've got a good
chunk of one definite piece of that done - a "resource repository", which
would implement most of your proposed interface (it has no knowledge of
requests at present); and a "config handler", which reads servlet init
parms, struts-config.xml, and web.xml and populates the resource repository.
To make sure I'm on the same page, a reference to an object implementing
your interface would be what's passed to the varions Action*.setServlet
methods instead of the ActionServlet. To make sense, all those method names
would need changed. Is that right?
Any other input?
Thanks,
Donnie
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, December 03, 2001 7:04 AM
To: Struts Developers List
Subject: Re: Multiple controller servlets
Donnie Hale wrote:
> Re: the proposed interface - I'd like to see one, perhaps a base interface
> for what you're proposing, which has access to everything for which the
> current request isn't needed. And that's most of those elements. That way
> all Struts elements that need the non-request-based resources can get at
> them without having to have a request around to do it. Also, they'll be
> there and accessible apart from a request anyway, so they should probably
be
> accessible.
If you wanted to take a pass as a base implementation of the interface I
outlined, that would be great. As you know, it could have immediate
application in VelServlet, since they could pass it the request and get
a handy API to the Struts resoruces in return.
I would be very much in favor of a classic, step-wise refinement of
ActionServlet that started with techniques like Extract Method and
Extract Class, to first make the current design easier to follow and
extend. Examples being the proposed ActionResource interface and the
suggestion of an ActionProcess class for the process* methods.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
----------
public interface ActionResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
----------
3) There should definately be a ActionServletProcess interface, and
associated base class implementations. The ActionServlet should be able
to choose between a conventional and multipart process now, and others
later. (Say, a VelocityProcess.)
----------
--
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 Donnie Hale <do...@haleonline.net>.
Ted,
I can see that. However, some of those collections are directly
FastHashMaps, and some are wrappers like ActionFormBeans. I've thought that
perhaps wrappers should be made for all of them to be consistent, and then
ActionResources would be as you say - a means for accessing a reference
which provides the underlying API.
Donnie
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, December 03, 2001 10:38 PM
To: Struts Developers List
Subject: Re: Multiple controller servlets
These wouldn't exist as such on the ActionResource interface I
suggested. These are really just shortcuts to the API for the underlying
resources, like
formBeans.addFormBean(formBean);
So, if someone wanted to do them through an ActionResources object, they
could do the same thing
actionResources.getFormBeans().addFormBean(formBean);
I believe the real reason they are on ActionServlet is for the digester.
The admin Actions are fun, but I doubt that they are used much, except
for reload, which calls a different set of methods.
But, again, my first thought for the ActionResource interface was to
expose the resources to other components.
The big ticket on ActionServlet would be to refactor those nasty
process* methods into a coherent helper object.
Donnie Hale wrote:
>
> Ted,
>
> There are a number of public methods on ActionServlet right now like:
>
> addDataSource
> addFormBean
> addForward
> addMapping
>
> Some of them are used in various actions package classes to do things
> dynamically. I'm guessing that there are deployed Struts apps out there
> which also use these methods as well.
>
> Do you have any thoughts on how this functionality should be supported?
> Would these be additional methods on your proposed interface?
>
> Thanks,
>
> Donnie
--
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>.
These wouldn't exist as such on the ActionResource interface I
suggested. These are really just shortcuts to the API for the underlying
resources, like
formBeans.addFormBean(formBean);
So, if someone wanted to do them through an ActionResources object, they
could do the same thing
actionResources.getFormBeans().addFormBean(formBean);
I believe the real reason they are on ActionServlet is for the digester.
The admin Actions are fun, but I doubt that they are used much, except
for reload, which calls a different set of methods.
But, again, my first thought for the ActionResource interface was to
expose the resources to other components.
The big ticket on ActionServlet would be to refactor those nasty
process* methods into a coherent helper object.
Donnie Hale wrote:
>
> Ted,
>
> There are a number of public methods on ActionServlet right now like:
>
> addDataSource
> addFormBean
> addForward
> addMapping
>
> Some of them are used in various actions package classes to do things
> dynamically. I'm guessing that there are deployed Struts apps out there
> which also use these methods as well.
>
> Do you have any thoughts on how this functionality should be supported?
> Would these be additional methods on your proposed interface?
>
> Thanks,
>
> Donnie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multiple controller servlets
Posted by Donnie Hale <do...@haleonline.net>.
Ted,
There are a number of public methods on ActionServlet right now like:
addDataSource
addFormBean
addForward
addMapping
Some of them are used in various actions package classes to do things
dynamically. I'm guessing that there are deployed Struts apps out there
which also use these methods as well.
Do you have any thoughts on how this functionality should be supported?
Would these be additional methods on your proposed interface?
Thanks,
Donnie
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, December 03, 2001 7:04 AM
To: Struts Developers List
Subject: Re: Multiple controller servlets
Donnie Hale wrote:
> Re: the proposed interface - I'd like to see one, perhaps a base interface
> for what you're proposing, which has access to everything for which the
> current request isn't needed. And that's most of those elements. That way
> all Struts elements that need the non-request-based resources can get at
> them without having to have a request around to do it. Also, they'll be
> there and accessible apart from a request anyway, so they should probably
be
> accessible.
If you wanted to take a pass as a base implementation of the interface I
outlined, that would be great. As you know, it could have immediate
application in VelServlet, since they could pass it the request and get
a handy API to the Struts resoruces in return.
I would be very much in favor of a classic, step-wise refinement of
ActionServlet that started with techniques like Extract Method and
Extract Class, to first make the current design easier to follow and
extend. Examples being the proposed ActionResource interface and the
suggestion of an ActionProcess class for the process* methods.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
----------
public interface ActionResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
----------
3) There should definately be a ActionServletProcess interface, and
associated base class implementations. The ActionServlet should be able
to choose between a conventional and multipart process now, and others
later. (Say, a VelocityProcess.)
----------
--
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>.
Donnie Hale wrote:
> Re: the proposed interface - I'd like to see one, perhaps a base interface
> for what you're proposing, which has access to everything for which the
> current request isn't needed. And that's most of those elements. That way
> all Struts elements that need the non-request-based resources can get at
> them without having to have a request around to do it. Also, they'll be
> there and accessible apart from a request anyway, so they should probably be
> accessible.
If you wanted to take a pass as a base implementation of the interface I
outlined, that would be great. As you know, it could have immediate
application in VelServlet, since they could pass it the request and get
a handy API to the Struts resoruces in return.
I would be very much in favor of a classic, step-wise refinement of
ActionServlet that started with techniques like Extract Method and
Extract Class, to first make the current design easier to follow and
extend. Examples being the proposed ActionResource interface and the
suggestion of an ActionProcess class for the process* methods.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
----------
public interface ActionResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
----------
3) There should definately be a ActionServletProcess interface, and
associated base class implementations. The ActionServlet should be able
to choose between a conventional and multipart process now, and others
later. (Say, a VelocityProcess.)
----------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multiple controller servlets
Posted by Donnie Hale <do...@haleonline.net>.
Re: double-check locking - it's definitely not safe following the normal
pattern in Java. There are some esoteric workarounds which use ThreadLocal,
but until the Java Memory Management JSR gets rolling, accepted, and
implemented; that's the way it is. The easiest fix is just to move a single
lock which, of course, means a coarser locking pattern. :( So the
implementation you showed looks correct.
Re: the proposed interface - I'd like to see one, perhaps a base interface
for what you're proposing, which has access to everything for which the
current request isn't needed. And that's most of those elements. That way
all Struts elements that need the non-request-based resources can get at
them without having to have a request around to do it. Also, they'll be
there and accessible apart from a request anyway, so they should probably be
accessible.
FWIW...
Donnie
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Sunday, December 02, 2001 4:52 PM
To: Struts Developers List
Subject: Re: Multiple controller servlets
Under the heading "A step in the right direction", how about if we
(meaning I) were to start with defining a simple "ActionResources" class
that encapsulated everything that is now available under a Action.*_KEY.
This comes down to:
public interface ActionResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
This could then be instantiated using the request
ActionResourcesBase shared = new ActionResourcesBase(request);
and passed in the request. .
We could then start refactoring things to look for this bean instead.
Initially ,it would mostly be looking things up under their key in the
context. But at some point, a different implementation of
ActionResources could get them from someplace else entirely.
Here's a question:
Does multiple ActionServlets mean multiple Actions?
Or should there still be one Action class implementation per
application, with all the ActionServlets drinking from the same well?
Do any multi-threading wizards out there have an opinion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2214
The code looks fine, but I'd be glad for a second on committing this.
(Developer votes welcome.)
-- 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>