On Sat, Jan 16, 2010 at 1:21 PM, Yoko Harada wrote:
> Do you already have this new JRuby runtime in somewhere? If you have,
> I want to start using classloader-global runtime for emedding API.
> Current thread safe model works under a limited case. I think I should
> rethink thread safe concurrent
Hi Charlie,
On Wed, Jan 6, 2010 at 9:58 AM, Charles Oliver Nutter
wrote:
> Ok, it's time to start biting off a big change: we need to make the
> JRuby runtime be classloader-global (i.e. static).
Do you already have this new JRuby runtime in somewhere? If you have,
I want to start using classloa
hello,
just need to give my 2 cents: static fields with state in a
webapplication is a synonym for "having concurrency problems" for me.
I just have a rough idea how classloaders work with j2ee but I do not
see how several threads can run with the same context classloader and
having only one runti
On Wed, Jan 6, 2010 at 10:29 AM, Rob Heittman
wrote:
> I have to think through this a bit. It should not be a problem to have a
> static runtime, and make everything to do with class loading
> classloader-specific. My concerns have to do with state; we have situations
> where the same applicatio
Hi Charlie,
On Wed, Jan 6, 2010 at 9:58 AM, Charles Oliver Nutter
wrote:
> Ok, it's time to start biting off a big change: we need to make the
> JRuby runtime be classloader-global (i.e. static).
>
> There's many reasons for this:
>
> * You won't have to pass a Ruby instance into object construct
I don't fully grok the implications of this, but like the other
responder, I'm managing a lot of individual Ruby runtimes. Some share
the same ruby classes (rails, app code), some need to be independent.
I've really enjoyed being able to control the classloader I hand to
the Ruby upon crea
It should also be stated that if this work impacts users too much then
it will be our motivation to move to a new major version of JRuby
before putting it in. If the impact is minimal then it makes things
so much easier for us since we won't have a maintenance branch to
support. That said, we nee
I have to think through this a bit. It should not be a problem to have a
static runtime, and make everything to do with class loading
classloader-specific. My concerns have to do with state; we have situations
where the same application embeds several JRuby runtimes that persist
different state a
Ok, it's time to start biting off a big change: we need to make the
JRuby runtime be classloader-global (i.e. static).
There's many reasons for this:
* You won't have to pass a Ruby instance into object construction
* Serialization will work, since it will just be able to grab the
classloader-glo
