[
https://issues.apache.org/jira/browse/GROOVY-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653449#comment-17653449
]
Eric Milles commented on GROOVY-10885:
--------------------------------------
It may be possible to remove extension methods by clearing the cache or causing
the module scanner to run again. In fact StaticTypeCheckingSupport offers
{{clearExtensionMethodCache()}}. The problem in terms of the runtime is that
extension methods are woven into the MetaMethodIndex of each MetaClass. There
may be API through MetaClassRegistry to reset the necessary caches. In fact
the two linked methods interact with the registry...
In terms of adopting and supporting OSGi APIs, like the [link
above|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#L102]
-- we would not have the expertise to set up a suitable test environment or to
watch over developments in OSGi environments to keep them up-to-date. I get
the sense you want to share the functionality that {{aem-groovy-console}}
provides rather than copy it. Maybe you could get that project to extract what
you need into some shareable form.
> 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)
