Loading...
Loading...
Using this topic, you can update the custom extensions in Mirth® Connect.
In Mirth® Connect 4.6.0, we significantly refactored the source code to allow extensions to not be tied to specific Mirth® Connect versions to streamline the installation and update process. We split parts of the Mirth® Connect code into different “core libraries”, each of which should seldom change. Each extension is now linked only to the core libraries that it uses, and it specifies the required minimum version of each of those core libraries. As long as the Mirth® Connect installation has the prerequisite core libraries, the extension can be installed regardless of its version.
The latest version of the core libraries can be found in the core-lib folder in your Mirth® Connect installation folder.
mirth-core-client
mirth-core-client-api
mirth-core-client-base
mirth-core-client-plugins
mirth-core-models
mirth-core-server-plugins
mirth-core-ui
mirth-core-util
To continue using custom built extensions, you will need to refactor your code to depend on the core libraries instead of depending on the Mirth® Connect source code.
These libraries no longer exist, so your extension should not link to them:
mirth-client-core.jar: These classes were moved into various other core libraries.
mirth-crypto.jar: These classes were moved into mirth-core-util.
donkey-model.jar: These classes were moved into other core libraries, primarily mirth-core-models.
Instead, your extension should link to these new core libraries:
mirth-core-client: Contains the Client class that can be used to make API requests to a server.
mirth-core-client-api: Contains servlet interfaces.
mirth-core-client-base: Contains classes needed for basic API hooks and base classes needed by the server and client.
mirth-core-client-plugins: Contains classes needed for client-side extension hooks.
mirth-core-models: Contains base model classes.
mirth-core-server-plugins: Contains classes needed for server-side extension hooks.
mirth-core-ui: Contains common Java Swing components and base classes used in the client.
mirth-core-util: Contains various utility classes.
mirth-server.jar
donkey-server.jar
mirth-client.jar
plugin.xml, source.xml, and/or destination.xml) to specify the core libraries it depends on and the minimum versions it requires. Initially, the minimum version should be 4.6.0 for each core library. Refer to the following example metadata XML file:
<pluginMetaData path="myPlugin">
<name>Plugin Name</name>
<author>Author</author>
<pluginVersion>4.6.0</pluginVersion>
<mirthVersion>4.6.0</mirthVersion>
<minCoreVersions class="java.util.Map">
<entry><string>mirth-core-client</string><string>4.6.0</string></entry>
<entry><string>mirth-core-client-api</string><string>4.6.0</string></entry>
<entry><string>mirth-core-client-base</string><string>4.6.0</string></entry>
<entry><string>mirth-core-client-plugins</string><string>4.6.0</string></entry>
<entry><string>mirth-core-models</string><string>4.6.0</string></entry>
<entry><string>mirth-core-server-plugins</string><string>4.6.0</string></entry>
<entry><string>mirth-core-ui</string><string>4.6.0</string></entry>
<entry><string>mirth-core-util</string><string>4.6.0</string></entry>
</minCoreVersions>
</pluginMetaData>PlatformUI is now located in the mirth-core-ui library, and PlatformUI.MIRTH_FRAME is now a FrameBase rather than a Frame. You will need to update your import statements or cast references to that field to a Frame.
DatabaseSettings.getProperties() has been replaced with DatabaseSettings.getProperties(Serializer serializer).
Subclasses of com.mirth.connect.donkey.util.Serializer must now implement <T> List<T> deserializeList(String serializedObject, Class<T> expectedListItemClass).
import statements accordingly. Refer to the following table for the changed packages. All packages begin with com.mirth.connect.
Classes | Old Package (com.mirth.connect…) | New Package (com.mirth.connect…) |
| client.core | util |
| connectors.email.server | connectors.core.email |
| connectors.email.server | plugins.ssl.server |
| connectors.file | connectors.core.file |
| connectors.file.filesystems | connectors.core.file.filesystem |
| connectors.file.filters | connectors.core.file.filters |
| connectors.http | connectors.core.http |
| connectors.smtp | connectors.core.smtp |
| connectors.tcp | connectors.core.tcp |
| connectors.ws | connectors.core.ws |
| donkey.server.data | donkey.model |
| donkey.server.message | donkey.model.message |
| donkey.server.message.batch | donkey.model.message.batch |
| plugins.httpauth | plugins.core.httpauth |
| plugins.httpauth.userutil | plugins.core.httpauth.userutil |
| server.message | model.message |
| server.util | util |
Custom extensions that include Connectors need some additional refactoring.
Connectors that are linked against the core libraries can no longer extend SourceConnector, DestinationConnector, or PollConnector. Instead they must implement SourceConnectorPlugin, DestinationConnectorPlugin, or PollSourceConnectorPlugin. They must provide an implementation for void initialize(ISourceConnector connector) or void initialize(IDestinationConnector connector) , depending on whether it’s a source connector or destination connector. Within the initialize method, the Connector should save a reference to the ISourceConnector or IDestinationConnector which can be used to call methods that were previously inherited methods from SourceConnector, DestinationConnector, or PollConnector.
SourceConnector class:
// Original class
public class MyCustomReceiver extends SourceConnector {
private void myCustomMethod() {
System.out.println("Channel ID: " + getChannelId()); // Calls the inherited method getChannelId()
System.out.println("Connector Name: " + super.getConnectorName()); // Calls the inherited method getConnectorName() via super reference
}
}
// Updated class
public class MyCustomReceiver implements SourceConnectorPlugin {
private ISourceConnector connector;
@Override
public void initialize(ISourceConnector connector) {
this.connector = connector;
}
private void myCustomMethod() {
System.out.println("Channel ID: " + connector.getChannelId()); // Calls method from ISourceConnector reference
System.out.println("Connector Name: " + connector.getConnectorName()); // Calls method from ISourceConnector reference
}
}HttpReceiver or WebServiceDispatcher, must add a new property to their metadata XML file named serverBaseClassName that specifies the fullyqualified name of the base class. In the following example, MyDispatcher extended HttpDispatcher:
<connectorMetaData path="myConnector">
<name>My Connector</name>
<author>Me</author>
<pluginVersion>4.6.0</pluginVersion>
<mirthVersion>4.6.0</mirthVersion>
<url>http://myurl.com</url>
<description>Some description.</description>
<clientClassName>my.connectors.myconnector.client.MySender</clientClassName>
<serverClassName>my.connectors.myconnector.server.MyDispatcher</serverClassName>
<serverBaseClassName>com.mirth.connect.connectors.http.HttpDispatcher</serverBaseClassName>
</connectorMetaData>The client connector needs to implement ConnectorSettingsPanelPlugin instead of extending a concrete Mirth® Connect class. In the implementation for void initialize(ConnectorSettingsPanelBase connectorBase) , it should save a reference to the ConnectorSettingsPanelBase object which can be used to call methods that were previously inherited from ConnectorSettingsPanelPlugin.
HttpListener, must add a property to their metadata XML file named clientBaseClassName that specifies the fullyqualified name of their base class. In the following example, MyListener extended HttpListener:
<connectorMetaData path="myConnector">
<name>My Connector</name>
<author>Me</author>
<pluginVersion>4.6.0</pluginVersion>
<mirthVersion>4.6.0</mirthVersion>
<url>http://myurl.com</url>
<description>Some description.</description>
<clientClassName>my.connectors.myconnector.client.MyListener</clientClassName>
<clientBaseClassName>com.mirth.connect.connectors.http.HttpListener</clientBaseClassName>
<serverClassName>my.connectors.myconnector.server.MyReceiver</serverClassName>
</connectorMetaData>