Rewrite the JSF backing beans

[matthias-ronge]

Description

This is about cleaning up and bringing up to date what is known as technical debt. Our JSF backing beans are inherited from a legacy development history. There was no consistent separation between the front-end side and the database side, which means that Hibernate database objects are kept in JSF sessions, which technically shouldn't be the case, and has always caused some problems. Occasionally, but at important moments such as creating processes, the same backing bean is used for two pages—this is completely unacceptable. JSF sessions and database objects are bound to the thread, but Tomcat uses a different thread for processing each HTTP request, which inevitably causes problems. It also prevents the open sessions from being saved cleanly when Tomcat is stopped and continued when it is restarted, which is actually possible with powerful magic. The requirement is that no database object is kept in any form class field. This came up again and I would like to suggest the following:

It could mechanically (by a sophisticated script) be created:

• a Java class for each JSF page,
• that correspond one-to-one. So,
• a class field for each property,
• with getters and setters that only read and write the field and never do more than that (we could also consider using Lombook annotations),
• with standardized, generated Javadoc, and
• a method hull for each interaction is created;
• for all for-each iterations in the JSF, a separate related class, the same in it,
• all of them @Serializable, and
• the naming strictly derived from the JSF, from ID and property. For example, for an element id="export" the property rendered as boolean exportRendered. (We can also think about whether to have a class with the properties for each JSF object. That seems sensible to me, I've looked for it, but haven't found a library of them yet.)
• The backing beans are only initialized in the constructor, and
• database objects are only fetched, handled and saved in the action functions. They are fetched anew each time and
• never saved in class fields, so there is a strict limes between the two realms.

The code for the hull of the action methods is then consistently copied and pasted from the existing sources, and adapted where necessary, so that there is no functional change.

Related Issues

(TBD, please stand by)

Expected Benefits of this Development

• Administrators can restart Tomcat without logged in users losing their current session.
• Developers benefit from a simple, clear code construct, even if it looks mechanical, but is understandable. It is also understandable for reviewers what changes development. Actions only happen in defined places.
• Employees can benefit from much improved response times, as JSF pages load much faster, and there will be no more Hibernate-related errors (such as lazy loading errors, object is bound to multiple sessions, and the like).
• Salespeople can point out the performance gain, because clicking in the application is much faster, and there is less unavailability due to server restarts.

Estimated Costs and Complexity

Code metrics:
XHTML pages: 36, fragments: 177 (total: 213 files)
XML tags (closing tags not counted separately): 6,516
XML attributes: 15,150, of which 3,710 with JSF expressions, of which 559 active elements and 286 non-trivial expressions
Tag types with JSF expressions: 97, attributes: 286

Example of trivial JSF expression: value="#{UserForm.userObject.language}"
Example of non-trivial expression: rendered="#{TemplateForm.template.workflow ne null and not empty TemplateForm.template.tasks}"

• high ~ 110 working days