Short-term displayer utility fix

Issue #18 resolved
Sheila Morrissey created an issue

In the short term, the displayer properties file generator should be changed NOT to generate a line for inherited properties – we do not want to hand edit files

i.e when generating the displayer properties files for the ICCModule –

http\:// Always

DON’t generate that line –org.jhove2.module.format.Validator is not the class we are generating properties file for

http\:// Always

Do generate that line – org.jhove2.module.format.ICCModule.icc IS the class we are generating properties file for

And our documentation should reflect that properties are set for the superclass as a whole (your example below, FormatModule/Profiles)

Comments (6)

  1. Richard Anderson

    I traced the execution of the DisplayerPropertyFileGenerator class to discover the location of the algorithm that causes the ReportableProperty features of inherited classes and interfaces to be included in the file outputted by this class' main method.

    DisplayerPropertyFileGenerator extends PropertyFileGenerator, whose createPropertyFile() method is invoked to collect the features and output the file.

    In order to collect the list of features, createPropertyFile() makes a call to FeatureConfigurationUtil.getProperitiesAsReportablePropertyInfoSet(), which includes the following logic that cause the features of inherited interfaces and superclasses to be included (expressed as pseudocode):

    • for the class specified
    • > for each accessor method having a ReportableProperty annotation
    • > > construct an I8R and ReportablePropertyInfo object
    • > > add the ReportablePropertyInfo object to the features list
    • > repeat above for each inherited interface of the current class
    • repeat above for each inherited superclass of the current class

    I can therefore implement a short-term fix for the stated problem, by adding a boolean parameter to the getProperitiesAsReportablePropertyInfoSet() method which specifies whether or not to include inherited properties.

    Note that this method is also used by some of the other utilities in Here is a call hierarchy tree that shows the dependant callers (omitting jUnit test callers).

    • FeatureConfigurationUtil.getProperitiesAsReportablePropertyInfoSet(String)
    • > PropertyFileGenerator.createPropertyFile()
    • > > DisplayerPropertyFileGenerator.main(String[])
    • > > UnitsPropertyFileGenerator.main(String[])
    • > traverser.ReportableTypeTraverser.extractReportablePropertiesInfo()
    • > > traverser.ReportableTypeTraverser.extractDocInfo()
    • > > > documenter.FormatModuleDocumenter.documentModule(Reportable)
    • > > > > documenter.FormatModuleDocumenter.main(String[])
    • > traverser.ReportableInstanceTraverser.extractReportablePropertiesInfo()
    • > > traverser.ReportableInstanceTraverser.extractDocInfo()
    • > > > traverser.ReportableInstanceTraverser.extractDocInfo()
    • > > > > traverser.ReportableInstanceTraverser.main(String[])

    Therefore the change I propose to the getProperitiesAsReportablePropertyInfoSet() method signature will require changes to several classes other than the class most closely associated with the issue's problem statement

  2. Richard Anderson
    • changed status to open

    Fixed by commit 401a662c8f07

    Added a boolean parameter (includeAncestors) to FeatureConfigurationUtil.getProperitiesAsReportablePropertyInfoSet() method, so that inclusion/exclusion of ReportableProperties inherited from interfaces and super-classes can be specified

    Created a legacy method having the original method signature, which calls the updated method with includeAncestors set to true. This minimized the number of changed needed to classes that depend on this method.

    The net effect is that the value of includeAncestors will be set as follows:

    false for DisplayerPropertyFileGenerator false for UnitsPropertyFileGenerator true for FormatModuleDocumenter true for ReportableInstanceTraverser

  3. Log in to comment