[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520480#comment-16520480
]
John Wagenleitner commented on GROOVY-8649:
-------------------------------------------
Just want to clarify that the ASM resolving is used at compilation in order to
build AST nodes for referenced classes instead of via reflection (and
classloader) as before. It does not affect runtime where things like object
equality and security mechanisms come into play.
Sounds like your use case was to prevent compilation by providing a custom
classloader. Another way to hook into the compilation process would be to
provide a custom {{ClassNodeResovler}}, [according to the
docs|http://docs.groovy-lang.org/latest/html/gapi/org/codehaus/groovy/control/ClassNodeResolver.html]
it is meant to be a "pluggable way to resolve class names".
With 2.5.0 out it's likely too late to undo the default. With the compiler
option to disable it and with other ways to hook in like a ClassNodeResolver,
does this address your issue?
> 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)
