You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by wo...@gmx.at on 2003/04/06 04:00:09 UTC
questions/suggestions regarding ActionServlet implementation details
dear people,
out of personal interest (I implemented a front-controller framework myself
some time ago) I had a look at the source of the
org.apache.struts.action.ActionServlet class.
in relation to this I have 3 questions/suggestions:
1.) the method processPath(...) uses the following code:
<snip>
path = (String) request.getAttribute("javax.servlet.include.path_info");
if (path == null) path = request.getPathInfo();
</snip>
googling "javax.servlet.include.path_info" turned up the
page
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/funcspecs/fs-invoker.html
I found the following:
(...)
Calculate the {PathInfo} for this request, either from request attribute
javax.servlet.include.path_info or by calling request.getPathInfo().
considering the words "either...or" I asked myself, why doing both in the
above code? Am I missing something?
2.) both overridden methods doGet(...) and doPost(...) call the process(...)
method without distinguishing the two requests.
inside the process(...) body getMethod() is used to make this
differentiation.
would it not be more appropriate (at least from the view of the stack ;o) to
override the service(...) method of HttpServlet
and call process(...) there? after all, service(...) does nothing more than
dispatching to one of the doXXX(...) methods.
this information is afterwards thrown away again by calling process(...) in
both of them, then getMethod() is used again...
not that method calls are that expensive, but still...
I do admit that this would involve handling all other request types save GET
and POST and call the default implementations
of the appropriate doXXX(...) methods.
3.) processActionCreate(...) uses DCL (double checked locking). there are
quite a lot of potential problems with this approach
to lazy instantiation, *especially* in multithreaded and J2EE environments.
(e.g. refer to
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
I might be missing something in this concrete case, as I did (so far) only
read the ActionServlet source code.
however, as the front controller servlet is (by definition) only
instantiated once, these problems could occur easily
in my opinion, especially on processors with multi-pipeline architectures
and on multiprocessor platforms.
alternatives (apart from synchronizing the whole method,which would
introduce a considerable performance glitch) would
involve instantiation on startup (not preferable) or using wrappers with
static reference variables (one for each type
that shall be "singleton-ed"). the JLS states that static members are
initialized when the class is used for the first time,
thus, as there are no other members, you get "implicit" lazy instantiation:
class HelperSingleton {
static Helper singleton = new Helper();
}
greetings & regards
wolfgang
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: questions/suggestions regarding ActionServlet implementation details
Posted by wo...@gmx.at.
thanx a lot craig for the quick answer. sorry about Q no. 3, must have
gotten the wrong (old) source
code by accident... good that you already dealt with it ;o)
greetings & regards
(...)
> > 3.) processActionCreate(...) uses DCL (double checked locking).
(...)
> You're looking at old code (probably 1.0 based) -- the DCL usage was
> removed a long time ago (early in the 1.1 development process).
>
> Craig McClanahan
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: questions/suggestions regarding ActionServlet implementation
details
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 6 Apr 2003 wolfy@gmx.at wrote:
> Date: Sun, 6 Apr 2003 04:00:09 +0200 (MEST)
> From: wolfy@gmx.at
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: questions/suggestions regarding ActionServlet implementation
> details
>
> dear people,
> out of personal interest (I implemented a front-controller framework myself
> some time ago) I had a look at the source of the
> org.apache.struts.action.ActionServlet class.
> in relation to this I have 3 questions/suggestions:
>
> 1.) the method processPath(...) uses the following code:
> <snip>
> path = (String) request.getAttribute("javax.servlet.include.path_info");
> if (path == null) path = request.getPathInfo();
> </snip>
>
> googling "javax.servlet.include.path_info" turned up the
> page
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/funcspecs/fs-invoker.html
> I found the following:
> (...)
> Calculate the {PathInfo} for this request, either from request attribute
> javax.servlet.include.path_info or by calling request.getPathInfo().
>
> considering the words "either...or" I asked myself, why doing both in the
> above code? Am I missing something?
>
This logic is designed to deal with the fact that ActionServlet might have
gotten executed directly as the result of a client request (the normal
situation) or as a result of a RequestDispatcher.include() call to include
its output in some larger response. In the latter case,
request.getPathInfo() returns the path information from the *original*
request, not the included request, so it is not the appropriate data on
which to base a decision of which action to execute.
See the Servlet Specification (version 2.2 or later) for more information
on how request dispatchers work and their relationship to the values
returned by the path-related methods on HttpServletRequest.
http://java.sun.com/products/servlet/download.html
>
> 2.) both overridden methods doGet(...) and doPost(...) call the process(...)
> method without distinguishing the two requests.
> inside the process(...) body getMethod() is used to make this
> differentiation.
> would it not be more appropriate (at least from the view of the stack ;o) to
> override the service(...) method of HttpServlet
> and call process(...) there? after all, service(...) does nothing more than
> dispatching to one of the doXXX(...) methods.
> this information is afterwards thrown away again by calling process(...) in
> both of them, then getMethod() is used again...
> not that method calls are that expensive, but still...
> I do admit that this would involve handling all other request types save GET
> and POST and call the default implementations
> of the appropriate doXXX(...) methods.
>
It's technically feasible to override service() as you describe, but you
would give up some of the other functionality provided by
HttpServlet.service() in the base class (including the fact that it deals
with things like HEAD requests and "If-Modified-Since" checks
transparently for you).
>
> 3.) processActionCreate(...) uses DCL (double checked locking). there are
> quite a lot of potential problems with this approach
> to lazy instantiation, *especially* in multithreaded and J2EE environments.
> (e.g. refer to
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
> I might be missing something in this concrete case, as I did (so far) only
> read the ActionServlet source code.
> however, as the front controller servlet is (by definition) only
> instantiated once, these problems could occur easily
> in my opinion, especially on processors with multi-pipeline architectures
> and on multiprocessor platforms.
> alternatives (apart from synchronizing the whole method,which would
> introduce a considerable performance glitch) would
> involve instantiation on startup (not preferable) or using wrappers with
> static reference variables (one for each type
> that shall be "singleton-ed"). the JLS states that static members are
> initialized when the class is used for the first time,
> thus, as there are no other members, you get "implicit" lazy instantiation:
> class HelperSingleton {
> static Helper singleton = new Helper();
> }
>
You're looking at old code (probably 1.0 based) -- the DCL usage was
removed a long time ago (early in the 1.1 development process).
> greetings & regards
> wolfgang
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org