Kirk Lund created GEODE-2290:
--------------------------------
Summary: 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
Reporter: Kirk Lund
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
dev@geode.apache.org]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
