Legacy Recovery
Overview
The term Legacy Recovery refers to the practice of taking an existing Windchill customization and converting it into an extension.
Approaches
There are two possible approaches when attempting a Legacy Recovery procedure: the choice of which one to implement will often depend on the extent of the touch points an application implements. For example, if a customization only has one listener, it would be a good candidate for a full conversion, whereas a complete UI may be better executed as a hybrid conversion.
| Conversion Type | Description |
|---|---|
| Full conversion | A complete hot loadable extension. |
| Hybrid | Keeps some original code in place to reduce effort, but the result will not be fully hot-loadable. |
Full Conversion
A full conversion type of Legacy Recovery involves replacing all the touch points with WEX-compatible code. For example, any scripts that add menus, or replacing all code that interacts directly with Windchill.
This can be time consuming and requires significant retesting of the application after the conversion is complete, but it does mean that the new extension will be full hot loadable just as a normal, new Windchill Extension would be.
Touch Points
A touch point is the code of a customization that interacts with Windchill. This is not an API call, but connections that initiate code execution in the customization.
The following are examples of touch points:
| Touch Point | Description |
|---|---|
| Command Line | A command line executed on the server, usually from a Windchill shell using the windchill.exe |
| User Interface | Various uses of the JSP using the Windchill UI JCA architecture. |
| Menus | Adding actions in to the actions xmls. |
| Data Utilities | Icons made available in tables. |
| Listeners | Listens for events in the system such as state changes. |
Hybrid Conversion
A hybrid Legacy Recovery conversion uses an approach of implementing a façade.
Façades
In this approach, the codebase of the extension is added to Windchill's codebase (as opposed to what happens in the case of a full conversion or a regular WEX, where the extension's codebase is kept separate following the WEX Platform's design principle of isolation) allowing the existing touch points to continue to function. The façade will often use the WexInvoker.invoke method to immediate pass the execution into the extension and thus the isolated ClassLoader.
The downside of this is that these facades are static and not hot loadable: this means that, after the first install, the server must be re-started. However, from this point onwards the main body of the code is hot loadable, which makes it not such a big price to pay having avoided the effort and investment of a full conversion.
Implementation
Fromwex-parent 2.8 upwards, the build supports the following property in the pom.xml:
<wex.legacy>true</wex.legacy>
This parameter will add the complete extension classes into the Windchill codebase here:
wex/codebase
This is part of the Windchill class path and these classes will be loaded by the system as required. Note that the classes, not the JAR files, are added to this location: this is deliberate as the JAR would have a file handle left open by the JVM, meaning that when the extension is undeployed (such as during an update) the files could not be deleted by the Platform. Using this technique ensures all files are deleted on the extension's uninstallation; note that an empty shell of the folder structure is left in place.
The build mechanism will also unpack any dependency that begins with the prefix wex- or wcom-. However, other third party libraries must be added by hand in the corresponding area as JAR files.