hi jukka, thanks for your config refactoring work and sketching options for future improvements.
having developed the greater part of jackrabbit's code base in an iterative process over the course of the last 2 1/2 years, trying to keep pace with the sometimes radical changes in the roughly 20 incarnations of the spec, i am absolutely aware that there's potential for improvement in various sections of jackrabbit's implementation. (phew, long sentence ;) currently we are still struggling with completing the implementation of 0.16.2 and i can already see 0.16.4 around the corner :( bearing this in mind, i currently tend to be in favor of option 0, maybe option 1. i am not saying that the other options are not worth considering, i'm just afraid that starting radical refactoring work at this point would cause too much distraction and hinder the completion of the implementation in terms of spec-compliancy. i suggest we re-consider more radical changes, unless they are absolutely necessary, once we've reached jsr 170 feature completeness. what do you think? cheers stefan On Tue, 08 Mar 2005 18:28:58 +0200, Jukka Zitting <[EMAIL PROTECTED]> wrote: > 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 > >
