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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
