FWD » Core Development » Conversion Tools

Actually that branch is long gone... so I created 9297a, which is ready for review. Claude wanted me to let the reviewer know about the following:

Side effect of the 9727a changes on datanames / codenames¶

This doesn't change how -? behaves. It's a side effect of what had to change to make -? work without a project configuration, and it can change normal conversion runs in one specific case.

1. Why these values had to change¶

Before this change, TransformDriver and ConversionDriver read the configuration while their classes were being loaded, before main() ran:

// TransformDriver
protected static final String datanames = Configuration.getParameter("datanames");

// ConversionDriver
private static final String codenames = Configuration.getParameter("codenames");

The static {} block in TransformDriver also read registry and binary-ast when setting up the AstManager. The JVM runs all of this as soon as it loads the driver class, so Configuration.getInstance() loaded cfg/p2j.cfg.xml before any command line argument was looked at. With no configuration, every driver invocation (-? and no arguments included) failed with an ExceptionInInitializerError stack trace, and main() never got a chance to print the syntax help.

2. What changed¶

The configuration is no longer read during class initialization:

• datanames is now the method TransformDriver.datanames() and codenames is now ConversionDriver.codenames(). Each one calls Configuration.getParameter() when it's needed. All call sites were updated, including the static ConversionDriver.generateWsdls() path used by GenerateWsdl.
• The registry / binary-ast reads moved inside the supplier passed to AstManager.initialize(). That supplier is only called when a plugin is first created, so AstManager setup no longer needs the configuration.

-? (and the other syntax errors) now exit before anything reads the configuration. When the configuration is needed and can't be loaded, the driver prints a one-line error plus the syntax help instead of a stack trace.

3. The side effect: profile overrides now apply¶

Because the values used to be read at class load time, they were always taken from the global <parameter> entries. -P<profile> hadn't been processed yet, and neither had a default profile.

They are now read when they are used, which is after the profile has been loaded (Configuration.loadConfigProfiles() / setDefaultProfiles()). In single-profile mode (one -P<name>, or exactly one profile marked as default), Configuration.loadProfile() clears parmMap and rebuilds it from the global parameters plus that profile's own parameters. So:

• If a project sets datanames or codenames inside a <profile>, the profile's value is now used. Before this change it was silently ignored in favor of the global value (or null if there was no global value).
• If a project sets them only globally, or not at all, nothing changes.
• Multi-profile mode (several -P options) doesn't modify parmMap, so it behaves the same as before.

I think the new behavior is correct, since a profile parameter that is silently ignored looks like a latent bug. Still, it is a behavior change: a project that defines either parameter inside a profile could get different name conversion results than before. None of the projects I checked (the hotel/hotel_gui variants, fwd_survey and adepre) set either parameter anywhere. If you know of a customer project that sets datanames or codenames inside a <profile>, please let me know.

Results of attached script:

--- no project (/tmp/tmp.pO1Y9APO3g/noproj)
PASS  CD -?
PASS  PTD -?
PASS  RD -?
PASS  CD -D2 -?
PASS  PTD -D2 -?
PASS  RD -D2 -?
PASS  CD no args
PASS  PTD no args
PASS  CD options only
PASS  PTD options only
PASS  CD no config
PASS  PTD no config
PASS  RD no args, no config
PASS  RD -D2, no config
--- cfg/ without p2j.cfg.xml (/tmp/tmp.pO1Y9APO3g/nocfg)
PASS  CD missing p2j.cfg.xml
PASS  RD missing p2j.cfg.xml
--- real project (/home/rfb/projects/hotel_gui_dev)
PASS  CD -? with config
PASS  CD dry run (-SL F0)
PASS  CD bad mode

passed: 19  failed: 0