代码之家 › 专栏 › 技术社区 › bozo

巨大的EAR部署

ear java-ee

3

bozo · 技术社区 · 17 年前

与第一点相关的是,如何在Netbeans中将外部依赖库与项目分开,以便项目在开发机器上编译,但当创建EAR/WAR/EJB时,它并不包含所有的依赖JAR,这使它变得巨大。

小丑

3 回复 | 直到 16 年前

1

4

kdgregory 17 年前

这就是为什么将依赖项从EAR中移出并移入共享目录是一个坏主意:通过将所有依赖项保留在EAR中,应用程序服务器能够干净地取消部署/重新部署该EAR,并回收它在JVM堆中使用的空间(对于Sun JVM,是permgen)。如果将某些依赖关系移动到共享库中,则可能会面临这些依赖关系将保持对EAR中定义的某些对象的硬引用的风险。这意味着EAR类无法删除,最终您的应用服务器将在permgen空间用完后崩溃。

我对SSH的建议是基于“VPN”是指Windows SMB的假设,在复制文件时有很多来回通信。使用SSH(或更准确地说,SCP或RSYNC),您可以使用连接的全部带宽。

如果这仍然太慢,你应该考虑改变你的基础设施。由于VPN对我来说意味着企业网络,也许你可以在与部署机器相同的网段上设置一台构建机器。从流程的角度来看,这是一个更好的主意:你不应该从开发人员工作站部署构建。相反,您应该将源代码签出到干净的环境中,进行构建,运行测试,然后进行部署。

另一种方法是查看您的特定应用程序服务是否支持“爆炸耳朵”——如果是,那么您只需上传已更改的JAR。

2

1

Thorbjørn Ravn Andersen 16 年前

一种合理的方法可能是在本地构建EAR,然后使用rsync镜像文件,然后触发重新部署。如果底层jar不改变,EAR文件的大部分内容也不会改变,因此您将从rsync算法中获得很大的好处。

3

0

gefrag 14 年前

你为什么不把你的库jar复制到/glassfish installation dir/glassfish/domain/domain1/lib,不要把它们打包到你的ear文件中呢?