庞大的 EAR 部署
我试图弄清楚如何通过相当慢的 VPN 连接将巨大的 (40-50 MB) EAR 文件部署到服务器。 EAR 包含在 Glassfish 中创建的 EJB 和 WAR 项目，90% 的文件大小来自使用的外部依赖库。
是否有人提出了一种从 Netbeans 优雅部署到生产系统的策略，其中部署（通过网络）仅针对真正需要的内容（即，仅一个 WAR，而不是整个 EAR，或仅一个库） ，而不是整个库子项目）。
与第一点相关，如何在Netbeans中将外部依赖库从项目中分离出来，以便项目在开发机器上编译，但在创建EAR/WAR/EJB时它不包含所有依赖JAR，这些依赖JAR是
也许我们需要编写自定义的 Ant 脚本？开始使用maven？
谢谢大家的热情回答，
博佐
I'm trying to figure out how to deploy a huge (40-50 MB) EAR file to the server through a rather slow VPN connection. The EAR contains EJB and WAR projects created in Glassfish, and 90% of the file size is from external dependency libraries used.
Has anyone came up with a strategy for elegant deployment to production system from Netbeans, where the deployment (over the network) is done only for what is really needed (i.e. just one WAR, not the entire EAR, or just one lib, not the entire libraries subproject).
Related to the first point, how to separate external dependency libs from project in Netbeans, so that the project compiles on development machine, but when the EAR/WAR/EJB is created it does not contain all the dependency JARs, which are making it huge.
Perhaps we need to write custom ant script? Start using maven?
Thank you all for kind answers,
Bozo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么不将库 jar 复制到 /glassfish 安装目录/glassfish/domains/domain1/lib 并且不将它们打包到您的 Ear 文件中？
Why dont you copy your library jars to /glassfish installation dir/glassfish/domains/domain1/lib and dont package them into your ear file?
这就是为什么将依赖项从 EAR 移出并移入共享目录是一个坏主意：通过将所有依赖项保留在 EAR 中，应用程序服务器能够干净地取消部署/重新部署该 EAR 并回收它在 EAR 中使用的空间。 JVM 堆（对于 Sun JVM，即 permgen）。如果将某些依赖项移至共享库中，您将面临这些依赖项将维护对 EAR 中定义的某些对象的硬引用的风险。这意味着 EAR 类无法删除，最终您的应用程序服务器将在用完 permgen 空间后崩溃。
我对 SSH 的建议是基于“VPN”指的是 Windows SMB 的假设，它在复制文件时有大量的来回通信。使用 SSH（或更准确地说，SCP 或 RSYNC），您可以使用连接的全部带宽。
如果这仍然太慢，您应该考虑更改您的基础设施。由于 VPN 对我来说意味着企业网络，也许您可以将构建计算机设置在与部署计算机相同的网段上。从流程的角度来看，无论如何，这是一个更好的想法：您不应该从开发人员工作站部署构建。相反，您应该将源代码检出到干净的环境中，进行构建，运行测试，然后进行部署。
另一种方法是查看您的特定应用程序服务是否支持“爆炸耳朵”——如果是，那么您只需上传已更改的 JAR。
Here's why it's a bad idea to move your dependencies out of an EAR and into a shared directory: by keeping all dependencies within the EAR, the app-server is able to cleanly undeploy/redeploy that EAR and reclaim the space that it used within the JVM heap (for Sun JVMs, the permgen). If you move some dependencies into a shared library, you run the risk that those dependencies will maintain a hard reference to some object defined within the EAR. This will mean that the EAR classes cannot be removed, and eventually your app-server will crash after running out of permgen space.
My suggestion of SSH based on the assumption that "VPN" mean Windows SMB, which has a lot of back-and-forth communication when copying files. Using SSH (or more correctly, SCP or RSYNC), you can use the full bandwidth of the connection.
If this is still too slow, you should look into changing your infrastructure. Since VPN implies corporate network to me, perhaps you can get a build machine set up on the same network segment as your deployment machine. From a process perspective, this is a far better idea anyway: you shouldn't be deploying builds from a developer workstation. Instead, you should check out the source into a clean environment, do a build, run tests, and then deploy.
An alternative is to see if your particular app-serve supports "exploded ears" -- if yes, then you just upload the JARs that have changed.
合理的方法可能是在本地构建 EAR，然后使用 rsync 镜像文件，然后触发重新部署。由于如果底层 jar 不更改，EAR 文件的大部分部分也不会更改，因此您将从 rsync 算法中获得巨大好处。
A reasonable approach might be building your EAR locally, and then use rsync to mirror the file over and then trigger a redeployment. As most parts of an EAR file do not change if the underlying jars do not change, you will get a big benefit from the rsync algorithm.