I don't know if these should go into core just yet. The cluster support I put on the wiki was going to work differently without any external libs. Basically each node would write the replicated current page of the other node to disk so each node has all page of all other nodes on disk. That's what I meant by transparent. Marek?
-igor On 12/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Hi, > > Matej developed some cluster code that is optimized for Wicket (it has > for instance a clustered page store) + Jetty and that uses Tomcat > tribes for cluster communication. I've tweaked (mainly separated it in > 3 projects to make the dependencies work) and tested it with > Teachscape. It looks good enough to be a 1.0 release. > > If people don't object, I'd like to make these projects part of our > core projects. I definitively want support this project, since we plan > to use it for Teachscape soon (on top of additional clustering of for > instance Lucene and JMX, for which we might use Terracotta). The > licenses are not a problem (Jetty and Tomcat Tribes mainly), and the > ASF headers and tests for it are all in place. > > Clustering support is listed here: > http://cwiki.apache.org/confluence/display/WICKET/Wicket+1.4+Wish+List > > Though that says: 'enabled by default', which I don't think we should > do. The default is fine, and you can cluster your Wicket app easy > enough (without changes to your code) by using this project and/ or > Terracotta (or tradional clustering if you are fine with using the > older session store). Enabling it by default would mean more > dependencies, which I don't think we should do. I'd also like to > stress that these projects don't affect other wicket projects in any > way. > > If no-one objects to making this a core project, I'd also like to turn > it on for the example project. If there is just one node in the > cluster, it will still run without any problems, so it wouldn't > endanger anything or make deployment more difficult. > > WDYT? > > Eelco >
