Deployment 玩框架、单个Jetty实例、部署多个项目、共享LIB

我正在尝试部署两个或更多独立的游戏！（1.2.4）基于 相同的Jetty实例

根据这项研究，显然有可能提取出 来自每个

PrjName.war/WEB-INF/lib

目录和位置的公共库 将它们放入共享库目录，即

jetty/lib/ext

我们有大量较小的独立项目，我们将 喜欢用Play实现！但所有这些都需要以相同的方式部署 Jetty实例共享所有LIB以减少RAM使用。我的假设正确吗？几个共享相同库的项目将减少总体内存占用

我尝试将所有lib放在共享位置，即

jetty/lib/ext

对单个项目有效，但部署第二个项目失败 打破了第一个

这似乎是EhCache实例冲突的问题

这是码头日志：

...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
       at java.lang.reflect.Method.invoke(Unknown Source)
       at org.eclipse.jetty.start.Main.invokeMain(Main.java:469)
       at org.eclipse.jetty.start.Main.start(Main.java:612)
       at org.eclipse.jetty.start.Main.parseCommandLine(Main.java:265)
       at org.eclipse.jetty.start.Main.main(Main.java:79)
Caused by: net.sf.ehcache.ObjectExistsException: Cache play already
exists
       at net.sf.ehcache.CacheManager.addCache(CacheManager.java:859)
       at play.cache.EhCacheImpl.<init>(EhCacheImpl.java:32)
       at play.cache.EhCacheImpl.newInstance(EhCacheImpl.java:41)
       at play.cache.Cache.init(Cache.java:241)
       at play.Play.start(Play.java:511)
       ... 42 more

。。。
在sun.reflect.NativeMethodAccessorImpl.invoke0（本机方法）处
位于sun.reflect.NativeMethodAccessorImpl.invoke（未知源）
在sun.reflect.DelegatingMethodAccessorImpl.invoke处（未知源）
位于java.lang.reflect.Method.invoke（未知源）
位于org.eclipse.jetty.start.Main.invokeMain（Main.java:469）
位于org.eclipse.jetty.start.Main.start（Main.java:612）
位于org.eclipse.jetty.start.Main.parseCommandLine（Main.java:265）
位于org.eclipse.jetty.start.Main.Main（Main.java:79）
原因：net.sf.ehcache.ObjectExistsException:缓存已播放
存在
位于net.sf.ehcache.CacheManager.addCache（CacheManager.java:859）
在play.cache.EhCacheImpl.（EhCacheImpl.java:32）
play.cache.EhCacheImpl.newInstance（EhCacheImpl.java:41）
at play.cache.cache.init（cache.java:241）
play.play.start（play.java:511）
... 42多

---

非常感谢您的帮助。

当您使用共享JAR时，Jetty将使用系统的来加载共享JAR中的类。而且，由于Play（几乎）是一个单例，因此启动的第二个应用程序将影响第一个应用程序，反之亦然。这就是您现在遇到的例外：Play尝试在相同的类加载器中用相同的名称实例化两个缓存。我可以考虑以下解决方案：

修复Playframework，使其能够处理这种情况

使用自己的缓存实现（不确定这是否是阻止两个应用程序协同工作的唯一原因）

为每个应用程序使用公共设置和复制JAR

对我来说，选项3听起来更好，因为您不必冒险使用框架，而且对于回归错误，它也更安全。关于内存占用，您可以使用visualvm验证内存消耗是否显著不同，以证明共享JAR的合理性