jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: Refactoring config handling
Date Tue, 08 Mar 2005 16:28:58 GMT
Hi all,

I wrote:
> Would anyone mind if I had a go at refactoring the config classes?

After a series of small steps over the last few days, I think I've now
reached the point where further work would require crossing the config
package boundaries. Thus I'm now about to close off by summarizing my
changes and proposing some areas for future work. Comments and
constructive criticism are welcome!

First of all, my changes in the org.apache.jackrabbit.core.config
package start at revision 156044 and end at 156527. You can browse
the config sources before and after my changes at [1] and [2]
respectively.

[1]
http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/src/java/org/apache/jackrabbit/core/config/?rev=155930
[2]
http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/src/java/org/apache/jackrabbit/core/config/?rev=156527

My changes include the following:

   * Centralized the XML parsing (ConfigurationParser)
   * Clarified configuration object states (constructed, initialized)
   * Improved configuration error handling (ConfigurationException)
   * Added lots of documentation (javadocs, package.html)
   * Removed duplicate code
   * Added simple configuration unit tests

The self-placed constraint on not crossing the boundaries of the config
package prevented the more ambitious refactoring options. This was a
good thing, as many of these choices have deep structural and behavioral
effects on the Jackrabbit design. I'll now try to summarize these
options as starting points for discussion and possible future work.


OPTION 0 - taking advantage of my work so far

There are quite a few places in Jackrabbit that duplicate especially the
BeanConfig.newInstance() functionality. Taking advantage of this new
method would remove error-prone bean instantiation code all around
Jackrabbit. Better error handling would come as an added benefit.


OPTION 1 - evolutionary improvements

Currently the config package has the following responsibilities:

    1. Representing the structured configuration information
    2. Parsing the configuration xml files
    3. Creating the directory structure of a fresh repository
    4. Creating workspace directories and workspace configuration files
    5. Managing the set of configured workspaces
    6. Instantiating and initializing file system implementation classes

I think that most of these responsibilities should be moved outside the
config package. I'd leave only the task 1 to the core.config package,
move task 2 to a core.config.xml subpackage, and move the rest of the
responsibilities outside the config package.

Task 3 should be a part of RepositoryImpl initialization, task 4 a part
of RepositoryImpl.createWorkspace(), task 5 a more general part of the
RepositoryImpl, and task 6 either the responsibility of a separate
FileSystemFactory or a part of all classes that contain a file system
component.


OPTION 2 - virtual configuration

The file system and XML dependencies of the current Jackrabbit
implementation is not necessarily the best choice for all possible
situations. If wanted, it would be possible to remove the hardcoded file
system dependencies and replace XML configuration file parsing with an
abstract configuration management interface.

I'm not sure how much a this kind of an approach is actually needed.


OPTION 3 - radical change

While working with the config classes I realized that their main purpose
(task 1 above) is to transfer configuration information from the XML
configuration files to Jackrabbit. In a way the config objects are
simply complex constructor arguments. This is especially notable in the
simple BeanConfig classes, that are essentially used as factory
parameters, but also the more complex RepositoryConfig and
WorkspaceConfig classes share the same feature.

Should we actually remove the config objects in favor of a Builder or
Factory pattern? This way the configuration information would be more
directly tied to instance creation and it would be easier to extend the
configuration format even at runtime.


I'm not really advocating any given option, and don't even know if there
is any major pressure on changing the way Jackrabbit is configured.
However I hope and believe that my config work so far makes it easier to
pursue any of these options.

BR,

Jukka Zitting



Mime
View raw message