[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516716#comment-16516716
]
Alexander Veit commented on GROOVY-8649:
Thank you John, your suggested workaround seems to work.
However, I doubt that it is a good idea to turn on {{asmResolving}} by default.
Classes in a JVM are supposed to be loaded by a class loader in a reasonable
hierarchy. If Groovy deviates from this rule it will probably break all sorts
of things like object equality, {{instanceof}} checks, security mechanisms
etc.. Especially in Java applications that use Groovy as an embedded language.
> 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)
[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516175#comment-16516175
]
John Wagenleitner commented on GROOVY-8649:
---
This might be due to the new class resolving strategy used by default in 2.5.0
which uses ASM to read class files on the classpath instead of a classloader. I
don't know of an easy way to disable the ASM resolving in order to revert back
to the prior behavior. But if you have the ability to pass in a
{{CompilerConfiguration}} to the {{GroovyClassLoader}} or other compiler your
using (assuming it's under your control), something like the following would
work to disable the ASM resolving and it would fall back to using the
classloader:
{code}
import org.codehaus.groovy.control.CompilerConfiguration
ClassLoader loader = this.getClass().getClassLoader()
CompilerConfiguration compilerConfig = new
CompilerConfiguration(CompilerConfiguration.DEFAULT)
compilerConfig.getOptimizationOptions().put("asmResolving", false)
GroovyClassLoader gcl = new GroovyClassLoader(loader, compilerConfig)
gcl.parseClass("def obj = new org.example.NonScriptableClass()"){code}
> 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)
