[rhauch]

We're getting familiar with the difficulties of self-hosted configuration. We hadn't thought about the implications of a "privileged" configuration repository, and I wonder if that solves the bootstrapping problems or just moves them around...

If you're dealing with lots of different repositories, then perhaps this might help. A bit more formal approach to it would be to use something like JBoss Overlord, which is a web-based governance tool (see here for a summary). Of course, you might also just prefer to keep the configuration files inside a VCS, too.

As to clustering, it's good to hear that you guys investigated that. My understanding currently is that two repositories can cluster even if they have (say) differing federation setups, but that mutations propagating between incompatible sections of repository will cause run-time errors. Is that not the case? Do repositories do some kind of validation when they connect to cluster?

Repositories do share some basic configuration when they join, so you really do want the repository configurations to be "mostly" the same. Where configurations will differ is in any process-specific details, such as ports or addresses or directories, etc. When you use variables for these, then the same repository configuration should be able to be used throughout the cluster.

Of course, in a complicated cluster of servers, you could have repository A on all of the processes in the cluster and repository B only on some of them processes.

We thought the great bulk of cluster communication is going on in Infinispan, which wouldn't be aware of MODE's configuration... is that wrong?

Well, Infinispan will definitely be doing a lot of communicating, but ModeShape does sent events across the cluster for indexing and JCR Observation. In 4.0, each process will also be keeping a journal of all events, which will enable us to improve indexing (especially when processes rejoin the cluster after leaving it at some earlier time) and to implement JCR Journaled Observation. However, in 4.0 we're also simplifying clustering such that ModeShape will just piggyback on top of the ISPN clustering configuration.

[yulgit1]

Reading through this thread, brings up a specific implementation question I never quite grasped  - how to subclass the FileSystemConnector?  I was able to create subclass with a one method override:

https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main/java/org/modeshape/connector/filesystem/LargeFileSystemConnector.java

But as the variables set by reflection are private, I included them again in the subclass (and tried doing something with them in an override of the initialize() method) but this caused conflicts between the class and subclass.  To make this work, Randall instructed me to remove the private reflection variables and initialize() method from the subclass and it worked.  But if it were really necessary to use the private reflection set variables and override initialize() in the subclass, is there a way of doing this, or is that a limitation of setting by reflection?

[rhauch]

But if it were really necessary to use the private reflection set variables and override initialize() in the subclass, is there a way of doing this, or is that a limitation of setting by reflection?

If it were necessary, you could either set them reflectively or you could create public/protected setter methods that set the private fields reflectively.

We decided to make them private, knowing that in the future we could always relax the access modifiers to make them protected and/or add protected setter methods (while it is not possible to make them more restricted at a later time). However, we do not want to expose public setter methods, since that would allow anyone the ability to change the behavior at runtime. If it is desirable, we can change some of these (e.g., except for the fields in the Connector base class, which will always be set by ModeShape and nothing else) to be protected fields. If so, please log an issue.