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