dlecan
commented
11 years ago JVM loads resources by analyzing jars in classpath alphanumerically sorted. What is the name of your application ?
Closed ghost closed 11 years ago
dlecan
commented
11 years ago JVM loads resources by analyzing jars in classpath alphanumerically sorted. What is the name of your application ?
ghost
commented
11 years ago the name is playehcacheplugintest_2.9.1-1.0.0-SNAPSHOT.jar
dlecan
commented
11 years ago Can you rename it "a_playehcacheplugintest" (eg.) in MY_PROJECT/project/Build.scala and try again ?
ghost
commented
11 years ago Thanks - now it picks up the ehcache.xml deployed in my own Jar although I'm not too exited about renaming my Jar to override the default Play ehcache.xml :)
According to this http://stackoverflow.com/questions/5474765/order-of-loading-jar-files-from-lib-directory its because Tomcat sorts the Jars in the lib folder that this solution works?
dlecan
commented
11 years ago According to this http://stackoverflow.com/questions/5474765/order-of-loading-jar-files-from-lib-directory its because Tomcat sorts the Jars in the lib folder that this solution works?
Yes it is. It would possible to rename project's jar when it is embedded in war package, by setting an option configured in your build file. Please open another issue if you need it.
ghost
commented
11 years ago Although we got Play to load our own ehcache.xml some developers on our team are complaining the exception mentioned in the ticket still happens on hot redeployment in JBoss EAP 5.1.2.
In a small proof of concept app I cant trigger the issue but in a larger app it now seems to happen often after adding /conf/ehcache.xml.
The report Im getting from other developers is that after adding the ehcache.xml it now happens every time the developers change a scala template even when running the app in Play standalone.
I dont think the contents of the ehcache.xml is causing the problem but just for good measure Im posting it here (the change thats important to us is to limit the cache to a physical size - here shown as 50Mb - instead of the default limit of 10000 objects which is not really a limit):
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../config/ehcache.xsd" updateCheck="false" maxBytesLocalHeap="50M">
<defaultCache
eternal="false"
timeToIdleSeconds="0"
timeToLiveSeconds="0"
overflowToDisk="false"
memoryStoreEvictionPolicy="LFU"
/>
</ehcache>Someone reported a similar issue with Play itself on Play Google group months ago. Search for "ehcache" in https://groups.google.com/group/play-framework/tree/browse_frm/month/2012-7?_done=/group/play-framework/browse_frm/month/2012-7?scoring%3Dd%26start%3D750%26&scoring=d&start=750&&pli=1
Weird thing, individual messages seem to have been deleted ?!?
Does it also happen with native Play reloading feature ?
dlecan
commented
11 years ago it now happens every time the developers change a scala template even when running the app in Play standalone.
Sorry, I didn't catch this. For me, this is a Play reloading issue, which should be reported to Play itself.
Do not hesitate to reopen this issue if you think something is wrong with Play2War.
Im moving this issue here from the Play issue tracker as they thought its was related to the war plugin.
I'm trying to override the ehcache.xml bundled inside play.jar in a Play 2 (2.0.4 java) app thats being deployed to JBoss 5 using the play2-war-plugin 0.8.1.
None of these methods to override the configuration works:
1) Deploy my own ehcache.xml in /conf. Someone in google groups reported this was working (in Play standalone I guess) but with 2 ehcache.xml on classpath I'm not having any luck with this on Jboss. Play consistently picks the one inside play.jar. Users will probably have mixed success depending on their classloader setup.
2) Use a servlet context listener that creates the CacheManager singleton instance before Play does thereby overriding the config file:
3) Remove ehcache.xml from play.jar and add it to /conf.
4) Create a new plugin written in scala that extends the default ehcache plugin and override how the cache manager is created. I disabled the default cache and added my own plugin to /conf/play.plugins.
Solution 2, 3 and 4 initially works when I deploy to JBoss - it reads the "/conf/my-ehcache.xml" that I supplied instead of the ehcache.xml embedded in play.jar. However if I let the server stand idle for a few minutes and then hot deploy the app again then I get the stacktrace below on redeployment. If I make quick redeployments then the bug does not manifest itself. Once the bug manifests itself all subsequent hot redeployments fail with the same stacktrace but I can fix it by stopping the JBoss server, clean its temp folders (maybe not necessary), redeploy app and restart server.
I have tried the solutions using both play2-war-plugin 0.7.3 and 0.8.1.
Stacktrace for 2) 3) and 4):