On Sun, 6 Apr 2003 [EMAIL PROTECTED] wrote:
> Date: Sun, 6 Apr 2003 04:00:09 +0200 (MEST)
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
