Thanks, Tim. I intended these static non-final fields to be, by convention, only modified during the configuration mode, but in any case didn't do much because I'm still looking for a comprehension solution to the (can we call it?) constructor injection problem.


Your post did come through on the code list, and I will answer you more fully there, after I slap my forehead and realize that I'm talking about a deprecated version of the Resource class. :) This project is moving quickly!


For you and others interested, Restlet 1.2 will feature a major redesign of Resource:


http://wiki.restlet.org/developers/172-restlet/226-restlet.html


-Tal



Tim Peierls wrote:

[Tried sending to code list, but I'm not sure it got through.]

Well, there are definitely some concurrency bugs here. Using public static non-final fields is a big no-no. 

Even if you made all this thread-safe, it's problematic: What if two separate Applications (in the same class loader, but from different jars, say) use completely different ScriptResource configurations?

How about creating a ScriptResourceConfiguration class to encapsulate all of these static fields, stashing an instance of this in a (Restlet) Context somehow, and looking that up at ScriptResource construction time?

--tim

On Mon, Mar 23, 2009 at 9:18 PM, Tal Liron <tal.li...@threecrickets.com> wrote:

...  Specifically, I would be very happy if you and others could take a look at the script extension I am working on in Restlet svn. It has two Resource-based classes that currently rely on a few static fields to configure some high-level stuff. This is not a problem as long as we are dealing with a single use of these classes, or multiple uses where we don't mind sharing the configuration details. I suspect that this is good enough for many use-cases, but I can also imagine situations where this would be a problem.


(Anybody: feel free to answer on the code mailing list. I started the discussion here because I feel this issue could impacts many users of Restlet, not just this specific contribution.)


-Tal



Reply via email to