Hi, I'm currently setting them in my Jetty configuration file, for development/testing.
This sets them as system properties, by calling System.setProperty() (using reflection). Most/all web container should allow you to set system properties in some way, and it seems these can be referenced in the configuration.xml files. I think you can also use the standard java -Dxx=yy syntax on the command line to set them. Many Thanks, Luke Noel-Storr. ---------------- Integrated Publishing Solutions Ltd. Tel: +44 (0)1926 889199 http://www.integrate.co.uk On 6 Feb 2013, at 14:28, Cody Burleson <[email protected]> wrote: > Luke, > > Where are you defining the values for those property variables? I'm > kind of in the same boat as you right now and have had similar > questions about cluster configuration. > > Sent from my iPhone > > On Feb 6, 2013, at 4:11 AM, Luke Noel-Storr > <[email protected]> wrote: > >> OK, >> >> I bit more experimenting, and I think I can answer my own questions a bit: >> >> I believe it is just the version and workspace FileSystem that needs to be >> unique to each node, and I have discovered that environment variables can be >> embedded in prefixes, so, for the version and workspace filesystem schema >> prefixes I have: >> >> <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/> >> >> and >> >> <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/> >> >> And, to give the nodes unique ids, but with a single repository.xml, I have: >> >> <Cluster id="${node.id}"> >> >> Does this seem like I'm on the right track? >> >> >> Many Thanks, >> >> Luke Noel-Storr. >> ---------------- >> >> Integrated Publishing Solutions Ltd. >> Tel: +44 (0)1926 889199 >> http://www.integrate.co.uk >> >> >> >> On 6 Feb 2013, at 11:03, Luke Noel-Storr <[email protected]> >> wrote: >> >>> Hi, >>> >>> Thanks for the answers, both. >>> >>> Regarding locks, from what I've read session locks won't work, but object >>> locks should. Can anyone confirm this. >>> >>> I think I will need to use locks as, as far as I can tell, JCR offers no >>> means of specifying unique keys, or of doing an atomic query+update. The >>> only two ways I've seen recommended of doing this are using locks, or using >>> single name siblings, as my "unique key" is made of a number of fields, >>> single name siblings seem to be an unlikely solution, unless the name I use >>> is some combination of all the properties and their values. >>> >>> Also, regarding the FileSystem, where the clustering page in the wiki says: >>> >>> >>>> Each cluster node needs its own (private) workspace level and version >>>> FileSystem >>>> (only those within the workspace and versioning configuration; the >>>> ones in the >>>> repository.xml and workspace.xml file) >>> >>> >>> Does this mean that I will not be able to use Oracle persistence for the >>> version table and the workspace file system, or, if I do, will each node >>> need to use a different schema object prefix pre-fix? (and can the node id >>> be automatically added to the prefix, like value="${node.id}_version"?) >>> >>> >>> Regarding using Oracle, I seem to have come across a strange bug, which >>> I've not yet been able to identify. When starting up a new repository on a >>> clean DB, you get an error "ORA-00955: name is already used by an existing >>> object" for every set of tables it tries to create. If you restart it then >>> gets past the error, but hits it again for the next set of tables. This >>> meant I needed to restart 4 times before it would run, once for the default >>> workspace, once for versions, and one for security, and then the final time >>> it worked. I'll try and have a dig into this when I get a bit more time, >>> but, wondered if anyone else had experienced this. >>> >>> I lost about two days to the bug, as every time I hit it I tried clearing >>> the database, changing some configuration, or settings, and then >>> restarting. It was only by chance that I finally found that a brute force >>> effort would finally get it running smoothly. >>> >>> >>> Many Thanks, >>> >>> Luke Noel-Storr. >>> ---------------- >>> >>> Integrated Publishing Solutions Ltd. >>> Tel: +44 (0)1926 889199 >>> http://www.integrate.co.uk >>> >>> >>> >>> On 5 Feb 2013, at 22:08, Ian Boston <[email protected]> wrote: >>> >>>> On 5 February 2013 20:57, Jeroen Reijn <[email protected]> wrote: >>>>> On Mon, Feb 4, 2013 at 11:10 AM, Luke Noel-Storr >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Also, and advice on locking would be appreciated. >>>>> >>>>> Sorry can't help you with this one. >>>> >>>> JCR locks will work within the same JVM but will not propagate >>>> reliably throughout a cluster since the replay of the journal (which >>>> is used to propagate the lock) is not synchronised with the writing of >>>> that journal. ie cluster nodes can fall behind. >>>> >>>> If you need cluster wide locks then you should probably use separate >>>> component. Since you have Oracle in the mix, a transactional lock >>>> within Oracle will be the easiest way of achieving this. Perhaps a >>>> table with a sha1of the path to be locked will work, with a simple IN >>>> query to select descendents. YMMV. >>>> >>>> >>>> HTH >>>> Ian >>
