geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-2290) Provide way to limit scanning of deployed jars
Date Sun, 16 Apr 2017 16:18:41 GMT


ASF subversion and git services commented on GEODE-2290:

Commit 6f7f943998153de1f00b1446eb80fa6d304ac40f in geode's branch refs/heads/develop from
[;h=6f7f943 ]

GEODE-2290: Limit scanning of deployed jars

 - Uses fast-classpath-scanner to scan jars for classes containing Functions without eagerly
loading all classes in the jar.

> Provide way to limit scanning of deployed jars
> ----------------------------------------------
>                 Key: GEODE-2290
>                 URL:
>             Project: Geode
>          Issue Type: Improvement
>          Components: gfsh, management
>            Reporter: Kirk Lund
>            Assignee: Jared Stewart
>              Labels: ClassLoader, DeployCommand, deploy, gfsh
> Currently if you use the GFSH command "deploy jar" the deployed jar will be scanned in
such a way that the deployer will load and resolve every .class file in the jar file. The
original intention of "deploy jar" was that only Functions would be deployed. Any .class that
is found to be a Function is automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as CacheListener.
If you then follow up the deploy with "alter region" you can alter the region to add the CacheListener
or other callback.
> Some users have reported trying to deploy a jar with much more than just Functions or
CacheListeners or domain classes used for Region Entries. If the jar includes a class that
the callbacks or domain classes don't directly use but that class requires a missing transitive
dependency, then the deployer will generate a NoClassDefFoundError when it tries to load and
resolve that class.
> Along with the potential NoClassDefFoundError, forcing every .class to be loaded and
resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar without having
the deployer generate NoClassDefFoundError. This requires something like one of the following
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on]

This message was sent by Atlassian JIRA

View raw message