Redefine uri classloader meaning #2278
Conversation
|
Will this break any existing applications? Your change means it will always pick the same CL that loaded JRuby but is there the possibility that somone intended to load from a different CL or would that not work unless jruby CL is parent of another? I guess I am asking if there is any chance of regressions to better understand the risk. |
|
the change is to pick always runtime.getJRubyClassLoader.getParent and this regression - well uri:classloader: is only used by |
mkristian
force-pushed
the
redefine-uri-classloader-meaning
branch
from
0a3feed
to
d51d452
Compare
|
@enebo now since #2055 is fixed without |
…time.getJRubyClassLoader this allows to set JRubyHome to uri:classloader:/META-INF/jruby.home for all situations where there is a jruby.home packed inside a jar. fixes problem with loadService and knoplerfish OSGi fixed missed test and cleanup javadocs and add more junit-tests for uri:classloader: make IsolatedScriptingContainer work on felix-4.2.1 and probably on other osgi frameworks outside the pax test cases
… the context-classloader
mkristian
force-pushed
the
redefine-uri-classloader-meaning
branch
from
3cb1927
to
b04987a
Compare
Redefine uri classloader meaning
|
@enebo I also made a little change before I merged it to use runtime.getJRubyClassLoader as meaning of "uri:classloader:/" which actually matches how |
|
Cool. Glad to see this work out for release. |
to use
uri:classloader:/only makes sense if jruby is really loading from theThread.currentThread().getContextClassLoader()(CCL), so in order to use it you first need to checkruntime.getJRubyClassLoader.getParentto be CCL and if not supply some alternative.this PR redefines
uri:classloader:/to beruntime.getJRubyClassLoader.getParentwhich always in all possible situation will pick the same classloader, the one which loaded jruby itself.