Nested element order should be according to method order

[gvanbrakel]

Order of nested elements should be the same as the order of declaration of the corresponding setter-methods. SenderPipe overrides setMessageLog, setInputWrapper and setInputValidator, but this is not reflected in the order in the FrankDoc:

public class SenderPipe extends MessageSendingPipe {

    @Override // to obtain proper order in FrankDoc and XSD
    public void setMessageLog(ITransactionalStorage messageLog) {
        super.setMessageLog(messageLog);
    }

    @Override // to obtain proper order in FrankDoc and XSD
    public void setInputWrapper(IWrapperPipe inputWrapper) {
        super.setInputWrapper(inputWrapper);
    }

    @Override
    public void setInputValidator(IValidator inputValidator) {
        super.setInputValidator(inputValidator);
    }

    @Override
    public void setSender(ISender sender) {
        super.setSender(sender);
    }

[mhdirkse]

This issue asks to remove the concept of "technical override" for config children. We should investigate the impact before doing that. I will create an XSD without technical overrides and compare it to the XSD we are currently working with. We can discuss the differences to make a decision what to do.

[mhdirkse]

I have created an XSD in which technical overrides are not ignored. This has the following effects:

• FileSystemSender, MongoDbSender and XsltSender get a child "Param" without description. This happens because an empty description is inherited by StreamingSenderBase from interface IWithParameters. This also applies to classes derived from the three mentioned classes.
• The same happens for the descendant classes of SapSenderBase, which are all named SapSender. A config child "Param" without description is inherited from IWithParameters.
• XmlValidator reimplements registerForward() without providing a description. This way the description is lost.
• XmlWellFormedChecker re-inherits registerForward() from IPipe and loses the description of that method.
• SoapWrapperPipe re-inherits registerForward() from IPipe and loses the description of that method.
• BatchTransformerPipe re-implements addParameter() without a description and thus the description is lost.
• JdbcIteratingPipeBase re-implements addParameter without a description and thus the description is lost.
• XsltPipe idem.

And the effect we want: SenderPipe gets MessageLog, InputWrapper and InputValidator.

[mhdirkse]

These effects can be mitigated by replacing an empty description by the inherited description. The drawback is that the XSDs become larger this way because descriptions are repeated.

[mhdirkse]

I think technical overrides are a useful feature: If there is a technical override, then the Frank!Doc is not affected. This issue identifies a case in which an overriden method should affect the Frank!Doc, while the method has no JavaDoc of its own. I propose we introduce a JavaDoc tag @ff.reintroduce. If a config child or attribute has that annotation, then the attribute or config child has to appear in the child (no technical override).

We can have a Java annotation @Reintroduce that does the same as @ff.reintroduce.

[mhdirkse]

This solution is very easy to implement.

[gvanbrakel]

There is no need to lose a description. If no description is specified, is should be inherited.

[gvanbrakel]

After analyzing, I agree with the proposed solution to introduce a Java annotation @Reintroduce.