On Tue, 19 Aug 2003, Jan Zimmek wrote:
>
> -> "Perhaps you can describe what you are doing in this thread"
>
> The Thread is simply needed, so that the Globals class can return the
> current Request/Response-Object at any time and anywhere within the rest of
> my source, without passing them as parameter.
>
If that's all you want, you do ***not*** need a separate Thread. All you
need is a ThreadLocal in a static variable:
public class CurrentObjects {
private static ThreadLocal requests;
private static ThreadLocal responses;
public static void setObjects(HttpServletRequest request,
HttpServletResponse response) {
requests.set(request);
responses.set(response);
}
public static HttpServletRequest getRequest() {
return ((HttpServletRequest) requests.get();
}
public static HttpServetResponse getResponse() {
return ((HttpServletResponse) responses.get();
}
}
Make sure that CurrentObjects.setObjects() is called somewhere early in
the processing of each request (on a Servlet 2.3 container, a Filter makes
sense). Now, anywhere in your code that you need the current objects,
just say:
HttpServletRequest request = CurrentObjects.getRequest();
HttpServletResponse response = CurrentObjects.getResponse();
and you get back the instances for the current thread.
Of course, you're still going to suffer the maintainability problems that
happen with global variables -- there is a reason that object oriented
developers pass things around explicitly :-) -- but you're trying to work
way too hard to accomplish your goal.
>
> What are your opinions about "complex threading issues" mentioned by David ?
>
>
> In the near future we want to port our PHP-driven framework/cms (which has
> been proven in development and production) to JAVA. So I am looking for the
> fastest possible way to do this, without developing anything new from the
> scratch.
>
>
Using your own threads, in the manner you described, is going to be fatal
to the portability of your code (because it breaks the servlet spec), and
also will needlessly harm your performance. Use ThreadLocal instead,
which does exactly what you need.
For more info, see the Javadocs on java.lang.ThreadLocal.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
