部署应用JARs到Apache Geode成员上
您可以将应用程序JAR文件动态部署到指定的成员或分布式系统中的所有成员上。 Geode会自动跟踪JAR文件的版本; 将已部署的JAR文件自动加载到CLASSPATH; 并自动注册JAR包含的所有函数(function)。
要在Apache Geode中部署和取消部署应用程序JAR文件，请使用gfsh的deploy或undeploy命令。 您可以部署单个JAR或多个JAR（通过指定JAR文件名或指定包含JAR文件的目录），也可以将部署指定到单个成员组或多个成员组。 例如，连接到要部署JAR的分布式系统后，可以在gfsh提示符处输入：
gfsh> deploy --jar=group1_functions.jar
此命令将group1_functions.jar文件部署到分布式系统中的所有成员。
要将JAR文件部署到成员组，请使用--group参数。 例如：
gfsh> deploy --jar=group1_functions.jar --group=MemberGroup1
在示例中，假设您已经定义了在启动成员时要使用的成员组。 有关如何定义成员组和将成员添加到组的更多信息, 请参阅 配置和运行集群 。 将位于指定目录中的所有JAR文件部署到所有成员：
gfsh> deploy --dir=libs/group1-libs
您可以指定JAR文件名或部署的JAR目录，但不能同时指定两者。
在整个分布式系统中,取消部署所有先前部署的JAR文件：
gfsh> undeploy
取消部署指定的JAR文件：
gfsh> undeploy --jar=group1_functions.jar
要取消部署指定的成员组所有JAR文件：
gfsh> undeploy --group=MemberGroup1
只有以前在MemberGroup1组中的成员上部署的JAR文件才会被取消部署。
要查看分布式系统中所有已部署的JAR的列表，请执行以下操作：
gfsh> list deployed
要查看指定成员组中所有已部署的JAR的列表，请执行以下操作：
gfsh> list deployed --group=MemberGroup1
示例输出：
Member | Deployed JAR | JAR Location
datanode1 | group1_functions.jar | /usr/local/gemfire/deploy/vf.gf#group1_functions.jar#1
datanode2 | group1_functions.jar | /usr/local/gemfire/deploy/vf.gf#group1_functions.jar#1
有关gfsh用法的更多信息，请参阅 gfsh.
JAR文件的部署位置
每个成员上写入JAR文件的系统位置由为该成员配置的deploy-working-dir Geode属性确定。 例如，您可以在gemfire.properties文件中为您的成员配置以下内容：
#gemfire.properties
deploy-working-dir=/usr/local/gemfire/deploy
此部署位置可以是本地或多个成员使用的共享网络资源（如安装位置），以减少磁盘空间使用量。 如果使用共享目录，则仍然需要在每个想要访问应用程序的成员上部署JAR文件，因为部署将更新CLASSPATH和自动注册函数(functions)。
关于部署JAR文件和集群配置服务
默认情况下，集群配置服务将部署的JAR文件分发到分布式系统中的所有Locator。 当你使用gfsh启动一个新服务器时，locator提供配置文件和部署的jar文件给成员，并把它们写到服务器的目录中。
请参阅 集群配置服务概述.
JAR文件的版本控制
将JAR文件部署到分布式系统或成员组时，将修改JAR文件名, 以在其文件名中的显示版本信息。 每个JAR文件名以vf.gf＃为前缀，并在文件名末尾包含一个版本号。 例如，如果您部署五次MyClasses.jar，则列出所有已部署的jar时，文件名将显示为vf.gf#MyClasses.jar#5。
部署新JAR文件时，接收部署的成员会检查JAR文件是否重复，可能因为JAR文件已经部署在该成员上，或者因为JAR文件已部署到与其他成员共同使用的共享部署工作目录。 如果另一个成员已经将此JAR文件部署到共享目录（通过对其目录中的最新版本进行逐字节比较来确定），则接收最新部署的成员不会将该文件写入磁盘。 相反，成员更新ClassPathLoader以使用已经部署的JAR文件。 如果在磁盘上检测到较新版本的JAR文件并且已在使用中，则部署将被取消。
成员开始使用JAR文件时，成员将获得文件上的共享锁。 如果成员通过部署接收到较新的版本，则成员将释放共享锁，并尝试删除现有的JAR文件，以使用较新的版本。 如果没有其他成员在现有JAR上具有共享锁定，则删除现有的旧版本JAR。
自动类路径加载
启动缓存时，新缓存会请求将当前工作目录中每个JAR文件的最新版本添加到ClassPathLoader中。如果JAR文件已经部署到ClassPathLoader，则在找到较新的版本时，ClassPathLoader会更新其加载的版本;否则，则不会有变化。如果检测到其他成员没有共享锁，则删除旧版本的JAR文件。
取消部署JAR文件不会自动卸载在部署过程中加载的类。您需要重新启动您的成员才能卸载这些类(在部署过程中加载的类)。
当缓存关闭时，它会请求将所有当前部署的JAR文件从ClassPathLoader中删除。
如果您正在使用共享部署工作目录，则共享该目录的所有成员应该属于同一个成员组。重新启动时，共享相同部署工作目录的所有成员, 将使用当前工作目录中的所有JAR, 来自动部署和自动加载到CLASSPATH中。这意味着有些成员可能会加载JAR，即使它们不属于收到原始部署的成员组。
自动函数(Function)注册
当你部署一个包含函数(Function) （换句话说，包含一个实现了Function接口的类）的JAR文件时，该函数(Function) 将通过FunctionService.registerFunction方法自动注册。 如果部署另一个JAR文件（使用相同的JAR文件名或其他文件名）中包含相同的函数(Function)，则会注册该函数(Function)的新实现，覆盖旧的。 如果取消部署JAR文件，则在部署时自动注册的任何函数(Function)都将被取消注册。 因为多次部署具有相同名称的JAR文件会导致JAR被重新部署，所以JAR中的函数(Function)在每次部署时都会被取消注册并重新注册。 如果具有相同ID的函数(Function)是从多个不同名称的JAR文件注册的，那么当这些JAR文件中的任何一个被重新部署或取消部署，则该函数将被取消注册。
在cache.xml加载期间，任何可声明的参数都被保存。 如果在JAR文件中找到的函数(Function)也是可声明的，并且具有与加载cache.xml保存参数的声明具有相同的类名，则会使用这些参数来创建函数(Function)实例，并且也注册这些函数(Function)。 因此，如果在cache.xml中多次声明相同但具有不同参数集的函数，那么当部署JAR时，将为每组参数实例化一个函数(Function)。 如果任何函数(Function)是使用cache.xml加载的参数进行注册的，则默认的无参数函数是不会被注册的。