[jira] [Commented] (GROOVY-10885) Make Groovy Extensions work in an OSGi environment

["Jochen Theodorou (Jira)" <ji...@apache.org>]

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

Jochen Theodorou commented on GROOVY-10885:
-------------------------------------------

I think Groovy does currently not properly support the removal of extension methods. We have [categories|https://docs.groovy-lang.org/latest/html/documentation/core-metaprogramming.html#categories] for this normally. But categories are also thread-local and usually bad for performance, thus not used as a standard mechanism like extension methods are.

Is there a specific use-case for this in Apache Felix (or elsewhere)? Of course I am aware of OSGI and what the point of OSGI is. This is just to be able to think more in the terms of a specific scenario. Not sure what [~daniel_sun] or [~emilles] think about this, but a general purpose implementation of this would require quite some changes. So maybe there is a more specific solution we could implement instead?

> Make Groovy Extensions work in an OSGi environment
> --------------------------------------------------
>
>                 Key: GROOVY-10885
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10885
>             Project: Groovy
>          Issue Type: Improvement
>          Components: groovy-runtime
>            Reporter: Roy Teeuwen
>            Priority: Major
>
> The current setup for loading in ExtensionModule's does not support groovy extensions correctly in OSGi (tested in Apache Felix).
> The reason is that the [MetaClassRegistryImpl|https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/runtime/metaclass/MetaClassRegistryImpl.java] creates an [ExtensionModuleScanner|https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/runtime/m12n/ExtensionModuleScanner.java], which scan's the classloader for every jar file with an ExtensionModule properties file. In an OSGi environment, the classloader does not have access to every jar file (bundle) by default.
> I have created an example of an OSGi compatible implementation, using a BundleListener to listen for the addition of a Bundle to the OSGi environment, and then use this to get a ClassLoader for this Bundle to load the ExtensionModule properties file of that Bundle: [Activator|https://github.com/orbinson/aem-groovy-console/blob/feature/update-to-groovy-4.x/groovy/groovy-osgi/src/main/java/groovy/osgi/activator/Activator.java]
> Open questions: 
> - What to do when a Bundle gets reloaded / removed, in an OSGi environment this can be done at runtime but I don't see any methods available in the MetaClassRegistry / CachedClass to remove MetaMethods 
> - Where is this code best hosted? Is it ok to make a new subproject named groovy-osgi that contains the code to make this work, or does Groovy not see this relevant in the groovy git project?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)