Re: [Jscheme-user] Re: Multiple independent interpreters

[Toby A. <tob...@pe...>]

Attached (assuming I remember to do so this time) is a small patch to
Import.java that I think has more sensible semantics (i.e. the semantics
I described below).

Toby.

On Mon, Mar 15, 2004 at 11:36:44AM -0500, bor...@ko... wrote:
> Hi,
> 
> I'd like to put 1 vote on that particular change. I already have the need
> to patch JScheme and remove the assignment of the classloader to the
> thread's context in my NetBeans plugin development (the IDE manages threads
> and class loading its own way and gets completely confused by what Import
> does). 
> 
> Best,
> Boris
> 
> Original Message:
> -----------------
> From: Toby Allsopp tob...@pe...
> Date: Mon, 15 Mar 2004 08:04:03 +1300
> To: jsc...@li...
> Subject: Re: [Jscheme-user] Re: Multiple independent interpreters
> 
> On Fri, Mar 12, 2004 at 02:11:17PM -0500, Jonathan A Rees wrote:
> > 
> > Each interpreter instance potentially also needs its own class loader
> > (for use by scheme code, not by jscheme itself).  Don't forget to
> > provide a way to set it in a newly created instance.
> 
> Yes, I was just looking at the class loader stuff in jsint.Import, and
> that will need attention for any serious J2EE use, and probably any
> serious use embedded in a larger application.
> 
> The current behaviour is to set the current thread's context class
> loader to the class loader that loaded jsint.Import when jsint.Import is
> initialised, then always use the class loader that loaded jsint.Import.
> 
> I propose that better behaviour is to never change the context class
> loader and to use either a user-specified class loader or, if none has
> been specified, the current thread's context class loader.