[
https://issues.apache.org/jira/browse/GEODE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907937#comment-15907937
]
ASF subversion and git services commented on GEODE-2290:
--------------------------------------------------------
Commit 5934e7e39751dba9f591900b35e49a880adb3cae in geode's branch
refs/heads/GEODE-2290 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5934e7e ]
GEODE-2290: Remove JarClassLoader
Cherry pick test from lazy loading branch
Enhance DeployCommandRedeployDUnitTest
Fixed backup of user jars
Fixed deploy tests
Fixed undeploy test
> Provide way to limit scanning of deployed jars
> ----------------------------------------------
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
> Issue Type: Improvement
> Components: gfsh, management
> Reporter: Kirk Lund
> 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 approaches:
> 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
> [email protected]]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
