groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Veit (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
Date Mon, 25 Jun 2018 13:06:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522257#comment-16522257
] 

Alexander Veit commented on GROOVY-8649:
----------------------------------------

John, thank you for this clarification!

If the runtime class loading hierarchy is not affected by ASM resolving I would no longer
consider this an issue. The compiler option is fine. Additionally I will look at the ClassNodeResolver
mechanism for future use.

> Class loading in Groovy 2.5 breaks class loading hierarchy
> ----------------------------------------------------------
>
>                 Key: GROOVY-8649
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8649
>             Project: Groovy
>          Issue Type: Bug
>          Components: class generator
>    Affects Versions: 2.5.0
>            Reporter: Alexander Veit
>            Priority: Blocker
>
> Prior to Groovy 2.5 GroovyClassLoader passed classes requested by script code like
>  {quote}def obj = new org.example.NonScriptableClass(){quote}
> to its parent class loader (hereby the NonScriptableClasses are Java classes).
> We use this behavior to allow or deny loading of Java classes with the parent class loader
based on certain annotations on the respective class.
> With Groovy 2.5 this behavior has changed. org.example.NonScriptableClass is no more
passed to the parent class loader. This breaks our security mechanism.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message