¡Jugar! framework, única instancia de Jetty, implementar proyectos múltiples, compartir libs

Question

¡Estoy intentando implementar dos o más Play independientes! (1.2.4) proyectos basados ​​en la misma instancia de Jetty.

Según this post que al parecer es posible extraer los de lib comunes de cada directorio y coloque PrjName.war/WEB-INF/lib en un directorio lib compartido es decir, jetty/lib/ext.

Tenemos un gran número de proyectos independientes más pequeños que nos gustaría implementar utilizando Play! pero todos deben implementarse en la misma instancia de Jetty que comparte todas las bibliotecas para reducir el uso de RAM. ¿Es correcta mi suposición de que varios proyectos que comparten las mismas bibliotecas reducirán la huella de memoria en general?

Mis intentos de poner todas las bibliotecas en una ubicación compartida, es decir, jetty/lib/ext funcionaron para un único proyecto pero la implementación del segundo proyecto falla y rompe el primero.

Parece ser un problema con las instancias de EhCache en conflicto.

Aquí es el registro de amarre:

... 
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 

Cualquier ayuda es muy apreciada.

Answer 1

Cuando utiliza jar compartido, Jetty utilizará el Classloader del sistema para cargar clases dentro de los jar compartidos. Y, dado que Play EhCacheImpl es (casi) un singleton, la segunda aplicación para comenzar influirá en la primera y viceversa. Esa es la excepción que está recibiendo ahora: Play está intentando instanciar dos cachés, en los mismos cargadores de clase, con el mismo nombre. Puedo pensar en las siguientes soluciones: Playframework

1. Fix para que pueda manejar esta situación
2. Use su propia implementación de caché (no estoy seguro si esto es lo único que impide a sus aplicaciones tanto para trabajar juntos)
3. Utilice una configuración común y jar réplicas para cada aplicación.

La opción 3 me suena mejor, ya que no tiene que arriesgarse con el framework y también es más seguro con respecto a los errores de regresión. Acerca de la huella de memoria, puede usar visualvm para validar si el consumo de memoria es significativamente diferente para justificar tarros compartidos.