Hi Rob,

Good suggestion!

On Sun, Feb 6, 2011 at 1:08 AM, Rob Heittman <rob.heitt...@solertium.com> wrote:
> Hi Yoko and all,
>
> 1.6.0 introduces a new system property to control a useful new
> behavior in the JSR223 implementation:
>
> org.jruby.embed.classloader: current | none
>
> as documented here:
> http://yokolet.blogspot.com/2011/01/embedding-api-refinements-for-jruby.html
>
> I have a small quibble with the feature. As documented, it sets the
> classloader to the classloader that was used to load the JRuby
> ScriptingContainer, which is a handy default behavior because it will
> catch all the material bundled in JRuby's JARs, and gems and other
> Ruby material should just work as expected.
>
> But the word "current" is often (mistakenly, IMHO) used to refer to
> the context classloader, that accessed via
> Thread.currentThread().getContextClassLoader(). And it has a meaning
> in ordinary English as well. So I think the use of the word "current"
> here for the property might be confusing, since in fact it sets a
> classloader that is not relevant to the current thread or the current
> invoking class, but actually the classloader that was used to load
> JRuby, likely at some other time and place that is not "current" in
> the natural use of the term.

I didn't think of a good naming, so chose "current" because the
classloader is currently used. I don't mind to change names.

>
> I have some cases where the context class loader would be useful, too.
> So I would prefer having three options:
>
> org.jruby.embed.classloader: context | jruby | none

So, you mean:

ScriptingContainer container = new ScriptingContainer(...);

- context
container.setClassLoader(Thread.currentThread().getContextClassLoader());

- jruby
container.setClassLoader(container.getClass().getClassLoader());

- none
// won't set any classloader


I think the change is good and doesn't harm anything. This option is quite new.

However, the name "jruby" is confusing to me because we have
"JRubyClassloader." Don't you have good idea for the second option
above?

-Yoko

>
> where "context" would inject the value of the context classloader at
> Engine invocation time, "jruby" would inject the ScriptingContainer
> classloader as "current" now does, and "none" continues to take no
> action as in the current implementation. I think "jruby" should still
> be the default, as that is what most people would want.
>
> If any of that makes sense, I'm happy to supply the patches.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to