1 it would be good to have a package html describing the strategies package.
2 consider implementing the logical interfaces using abstract classes for RuleFinder and RuleLoader. it is unlikely that implementations will every need to extend anything else and the interfaces may possibly need to be varied later whilst retaining backwards compatibility. (for example, you may find it necessary to pass in a context object.)
3 i like the package documentation for plugins.
4 consider whether you could factor the code in LogUtils in a different way so that it would be possible for users to use a logging strategy plugin. it might possible now to find a home for this method and add a parameter or two whilst retaining the usual default behaviour.
5 consider whether to remove the resources parameter from:
the public PluginManager(PerDigesterResources r, PluginManager parent)
(since the resources should probably be from the manager). it's easy to add new constructs to an API if there is a demand.
6 in some ways, PerDigesterResources is a context object. consider whether (in the future) it might be useful to add other methods which might not fit so well with the name. a possible candidate for owning the logging strategy.
7 one thing that i have learnt over the years is that good naming is very important when creating a component API. an API that is shipped with a jakarta product may be in use for many years. a good name often indicates that the API is well thought out. a good API is also as small as possible (but no smaller ;) since it is easy to add new methods but hard to correct those mistakenly added. consider whether the class names reflect the roles they play and that each can be justified.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
