In this case, I think it's OK (though not ideal) to downgrade this one case to a warning, although it's better to encourage correct use of plugins:
1. don't configure a self-named plugin that has no implementations 2. for the "sort" case, configure the default explicitly (where it is visible and easy to change) instead of letting the absence of a plugin invoke an invisible default. Leave the other error logs alone, since many of the places that PluginManager logs an error *are* serious error conditions. They flag inconsistencies and errors in the configuration that are easy to make and have serious consequences (e.g. when the plugins you thought you configured are mysteriously gone and a media filter run fails..). /lcs > As I had mentioned previously, I am noticing errors logged in dspace.cfg > whenever the org.dspace.content.crosswalk.XSLTDisseminationCrosswalk is > accessed from the following configuration in dspace.cfg: > > plugin.selfnamed.org.dspace.content.crosswalk.DisseminationCrosswalk = \ > org.dspace.content.crosswalk.MODSDisseminationCrosswalk , \ > org.dspace.content.crosswalk.XSLTDisseminationCrosswalk, \ > org.dspace.content.crosswalk.QDCCrosswalk, \ > org.dspace.content.crosswalk.XHTMLHeadDisseminationCrosswalk > > I've now run across a *similar* error logged by the > 'org.dspace.sort.OrderFormatDelegate', as it is not configured in > dspace.cfg by default: > > # Uncomment the configuration below to use the multi-lingual MARC 21 > title ordering. > # > #plugin.named.org.dspace.sort.OrderFormatDelegate= \ > # org.dspace.sort.OrderFormatTitleMarc21=title > > > It's my belief that these sort of minor "errors" should really be > *WARNING* messages when they are logged to the dspace.cfg. The lack of > configuration for either of these plugins is not a problem in DSpace > (there are defaults that work perfectly well). > > Is anyone out there opposed to changing the PluginManager such that it > only logs WARNING level messages for unconfigured plugins? Is it really > appropriate to fill up logs with ERROR messages that aren't really errors? > > (An aside: as a manager of a production-level DSpace system, I'd *like* > to be able to configure Log4j to send me an email whenever it gets an > ERROR message. But, these sort of non-ERRORs just end up flooding me > with emails I don't need or want.) > > I'd like to make this modification for the 1.5.2 release, but I want to > be ensured that others are in agreement. Discussion? Thoughts? > > - Tim > > -- > Tim Donohue > Research Programmer, IDEALS > http://www.ideals.uiuc.edu/ > University of Illinois > [email protected] | (217) 333-4648 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
