1 Dec
2014
1 Dec
'14
8:53 p.m.
Thomas Mortagne wrote:
Yes, I'm coming around to thinking that's the simplest approach. I tried setting
the Context to reloadable in xwiki.xml and adding my component as a watched resource:
<Context path="/xwiki" docBase="/usr/lib/xwiki"
privileged="true"
allowLinking="true" crossContext="true"
reloadable="true">
<!-- make symlinks work in Tomcat -->
<Resources className="org.apache.naming.resources.FileDirContext"
allowLinking="true" />
<!-- allow hot reload of my component -->
<WatchedResource>/usr/lib/xwiki/WEB-INF/lib/mycomponent.jar</WatchedResource>
</Context>
This seemed to trigger a reload of the whole of XWiki, which wasn't pretty, though it
did do the job. Alas it generated a lot of errors in the log in the process, of the form:
SEVERE: The web application [/xwiki] registered the JDBC driver [org.postgresql.Driver]
but failed to unregister it when the web application was stopped.
SEVERE: The web application [/xwiki] created a ThreadLocal with key of type
[com.xpn.xwiki.store.migration.AbstractDataMigrationManager.ThreadLock] (value
[com.xpn.xwiki.store.migration.AbstractDataMigrationManager$ThreadLock@334be165]) and a
value of type [java.lang.Integer] (value [0]) but failed to remove it when the web
application was stopped.
And lots more of the above. So I won't be doing this...
Incidentally, I think I was wrong about old code persisting after a restart of Tomcat - I
reckon I just missed a step in my process.
I notice that
in the Tomcat docs there is a reloadable attribute for the
org.apache.catalina.Loader interface
[...]
Doesn't that mean that the corresponding XWiki class could support
reloading as a configurable option?
You don't win much time by relaoding Tomcat instead of restarting it,
the purely Tomcat side is quick compared to XWiki init.
Usually the best is to test everything you can using junit (plus and
you always sleep better with a good code coverage :)) and only test a
few complex scenario hard to mock with the complete stack.