Reducing Visible Configuration in CAS4

One of the issues we always had with CAS3 was the amount of Spring XML Configuration one was exposed to, whether it needed to be changed or not, and the management of those files.  If we added/removed/changed anything in the available Spring configuration files, upgraders would have to double check it against their configuration files to make sure they didn’t miss anything.

We tried our best to isolate user changes from the software configuration through things like the deployerConfigContext.xml and the Maven overly of a more fine-grained set of Spring XML configuration files.  Despite our best efforts, its still not great.

We’re looking to make progress on this in CAS4.  So far, we’ve identified the following areas where we can make improvement:

• Items that require no configuration, but just to be “wired” up will have their default configuration files included in the JAR that the class is included in.  This way, for example, if you need the default InMemorySessionStorage, you include the appropriate JAR as a Maven2 dependency.  Within that JAR, we have a Spring XML configuration pre-configured with the appropriate beans, and its just automatically loaded.  We would combine this with autowiring so that other components can find and inject the SessionStorage.  Another example, would be that the InMemorySessionStorage may need a set of SessionFactories.  You could wire them up automatically, or Autowiring could locate them and inject them automatically.  Clearly, there are some limits to this.  Things that will be heavily customized or have specific ordering needs would need to be manually wired.
• Items that shouldn’t change shouldn’t show up.  The CAS protocol specifies a set of URLs that need to be exposed.  But they are part of the protocol.  Why should they show up in the configuration files only so that we can tell you not to touch them.  For things like this, we’ve come to rely on Annotations wherever possible (i.e. the Spring MVC Annotations)
• Identifying “reality” extension points, and extensions points that just exist because we can.  We’re taking a closer look (we’ll go into more detail in a different post) at the extensions and collaborators we are exposing just because we can vs. what we’re exposing because we should. Going hand-in-hand with this is relying on sensible defaults for those things that are in-between we should expose them and we’re exposing them just because we can.

We’re hoping that the changes above, and any other changes identified (either on-list or in the comments below) make it easier for people to configure CAS.  As code starts to show up into our Subversion, we’ll go into more detail.