My favorites | Sign in
Project Home Downloads Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 47: Management of Rhino Context ThreadLocal
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  Nov 2010

Sign in to add a comment
Reported by, Nov 15, 2010
In my application I JSLint a lot of files over a long time. To get performance right, it's essential that I can keep a JSLint instance ready and configured between several invocations of JSLint.lint().

These invocations happen on servlet requests, hence not in the same thread.

Rhino has a ThreadLocal to manage the Context associated with the current running thread. JSLint4Java initialises this ThreadLocal in JSLintBuilder constructor, and then doesn't manage it further.

This causes problems for any JSLint instance in long running applications.

Attached is a test case that demonstrates the problem.

Attached is also another file that I currently use to get around the problem - essentially a wrapper that makes sure the Rhino thread local is managed properly - but I hoped that something like this could be merged into
991 bytes   View   Download
3.9 KB   View   Download
Nov 27, 2010
Project Member #1
A test case!  How marvellous! :)

I completely agree that JSLint should be usable without complication in a multi-threaded environment.  Thanks for spotting this; I'll try and get it worked in.
Status: Accepted
Labels: Milestone-Release1.5
Nov 27, 2010
Project Member #2
(No comment was entered for this change.)
Nov 29, 2010
Project Member #3
Fixed in

Now I understand the difference between contexts and scopes in rhino. :)
Status: Fixed
Nov 29, 2010
W00t! Release! Release! ;)

Without any deeper understanding of Rhino, it seems to be the thread local context thing is just an ugly solution to starting with a static api.

Jan 2, 2011
Project Member #5
(No comment was entered for this change.)
Labels: Milestone-Release1.4.5
Sign in to add a comment

Powered by Google Project Hosting