groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Theodorou (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8227) Allow to specify Groovysh (and GroovyShell) class loader different from TCCL
Date Mon, 12 Jun 2017 19:46:01 GMT


Jochen Theodorou commented on GROOVY-8227:

I am not sure I can follow what you  say. Thread.getContextClassLoader is used in many places
in Groovy, yes, but in most cases those are alternative usages. For example has Groovysh a
constructor in which you give a classloader, but another in which you do not do that, which
causes the context class loader to be used instead. It is similar for GroovyShell. If you
have a case in which a class loader or its children has not been propagate correctly, please
tell us about that.

In some cases we use the context class loader as fallback, after other tries failed. Is that
wrong for your case?

> Allow to specify Groovysh (and GroovyShell) class loader different from TCCL
> ----------------------------------------------------------------------------
>                 Key: GROOVY-8227
>                 URL:
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-runtime, Groovysh
>    Affects Versions: 2.4.x, 2.5.x
>         Environment: OSGi (Karaf 2.x, 3.X or 4.x)
>            Reporter: Denis Jouvin
>              Labels: classloader, groovysh, groovyshell
>             Fix For: 2.4.x, 2.5.x
>   Original Estimate: 48h
>  Remaining Estimate: 48h
> Allthough the Groovy API seem to allow one to specify the class loader when instanciating
a Groovysh or GroovyShell, internally in some places Groovy will silently use the TCCL (thread
context class loader) and there is no way to avoid that without hacking Groovy and chasing
all the places where {{getThreadContextClassLoader()}} is used.
> This is problematic, especially in OSGi environement, since the TCCL is not compatible
with OSGi principles (i.e. every bundle has its own class loader), and also with some modern
modular containers similar to OSGi. When a class loader is specified in the GroovyShell or
Groovysh creation, Groovy should propagate that class loader correctly (or instanciate children
class loader of that specified class loader), and in no way use the TCCL.
> This may be a dupplicate of [Groovy 4895|]

This message was sent by Atlassian JIRA

View raw message