Management port

Management port

The management port is the means that TBA communicates with TrustBuilder Servers. The default port is 8888 when installed as Trustbuilder Core and 9998 when installed as part of IdHub.

Amongst others this port can be used to:

  • Export a configuration in an zip format
  • Import a configuration in a zip format you have to use it in the engine
  • Reload the engine (Reuse the same instance)
  • Restart the engine (Create a new instance, drop the existing)
  • Get the statistics of all requests since start (requires enabled performance monitoring)

Default Value

The default port for the Management port is 8888. When starting, TrustBuilder starts or tries to start on this port, in the event that this port is already in use, this default can be overwritten.

Overwriting the default value

In the event the port is already in use you can override this port in 2 different ways:

  • via a java system property (only if 1 engine in the VM)
    • eg. -DTBADMINSOCKET=1234
  • via a jndi property TBADMINSOCKET (best option)

The managment port can be disabled by using port number -1

AgentId header

In order to make a call to the TrustBuilder Core administration port, you need to supply the header called AgentId. The content of the header can be created with the Password tool (see TrustBuilder Core - Reference - Tools)

Possible administrator actions

Once the engine is started this socket allows to do the following actions:

http://trustbuilder:port/version Retrieve the version number of the remote trustbuilder
http://trustbuilder:port/reload Reload configuration in an existing trustbuilder
http://trustbuilder:port/restart Stop and start the trustbuilder engine
http://trustbuilder:port/shutdown Stop the trustbuilder engine
http://trustbuilder:port/export Download the trustbuilder configuration as a zip-file
http://trustbuilder:port/import Upload a zip-file containing local config into the remote TB_HOME
http://trustbuilder:port/stats Return statistics for all requests handled so far in the engine

Monitoring trustbuilder

In the admin GUI a basic monitoring is avaible to check the timing of each component. First select the instance you want to monitor in the dropdown box.

For a local instance there is no extra configuration needed. A remote instance has to have jmx enabled to call the mbeans. Working with this screen is straightforward , select an instance, put on automatic monitoring and select the checkboxes of the values you want to graph.

The min, avg and max column gives the timing in milliseconds a script or an adapter took to complete the request. You can reset the values with the "reset data" button.

This monitoring is only for the trustbuilder adapters and scripts, you can also log performance statistics with the "Editing Suite" in the configuration of your instance. Monitoring of the WAS Server statistics is not part of this.



This provides a means to vary the decoration or look of TBA. Changing a theme does not change any functionality or feel of TBA.

There are 3 themes currently available the default, full colour coordinated, TBA, a minimal theme using less colours and a light theme using colours in a subtle manner.

Changing Themes

To change the desired theme select a different theme from the select box in the top right of the screen.

The chosen theme is stored in a cookie so that it is persisted between sessions. If the cookie is deleted the theme will revert to the default.

Overriding Styles

Individual CSS classes can be overridden by adding them to the /css/override.css file located in the trustbuilder-admin.war.

To do this requires experience and knowledge in CSS.

Administrator Troubleshooting

Memory Leaks

It has been observed when running the TrustBuilder Administrator (TBA) on Tomcat (6 and 7) there is a warning logged concerning a memory leak when Tomcat is shut down.

This has only been noted when using Tomcat but if you are experiencing memory issues with WebSphere or JBoss the same may apply. The basic fix is to remove the jaxb library from the application and load it at the container level in a shared lib or similar mechanism.

This memory leak warning is created in the [tomcat-home]/logs/catalina[date].log file thus:

SEVERE: The web application [/trustbuilder-admin] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@6a724da1]) and a value of type [java.util.WeakHashMap] (value [{class be.securit.trustbuilder.admin.gui.model.layout.Element=java.lang.ref.WeakReference@7646bb9f, class be.securit.trustbuilder.admin.gui.model.layout.ScriptBeforeFileID=java.lang.ref.WeakReference@1dc80063, class
but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
17-sep-2013 15:21:45 org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 

This is due to a Java library that is being used called JAXB. This library facilitates mapping of XML files to Java objects so that the configuration file can be loaded from an XML file and saved back to an XML file.

To avoid this error the library needs to be loaded by the container's class loader. What this means is that Tomcat should load the library not TBA (the application).

To enable this follow these steps.

The steps will remove jaxb-impl-x.x.x.x.jar from the trustbuilder-admin.war and place it into the [tomcat-home]/lib directory.

  1. Shut down Tomcat
  2. Locate the application. In a normal installation this will be a .war file trustbuilder-admin.war in the Tomcat home directory
  3. Open the war file. The war file is just an archive like a zip or tar file and can be opened with common compression tools (such as 7zip)
    • e.g. with 7zip installed on Windows right click the trustbuilder-admin.war and choose 7zip > Open Archive
  4. Navigate to the WEB-INF/lib directory within the war file
  5. Copy the jaxb-impl-x.x.x.x.jar from the archive to [tomcat-home]/lib
    • e.g. with 7zip installed on Windows drag the jaxb-impl-x.x.x.x.jar from the war to the folder
  6. Ensure the jaxb-impl-x.x.x.x.jar is no longer in the war file
  7. Save the war file
    • e.g. with 7zip installed on Windows just close 7zip
  8. Start Tomcat

Now when Tomcat is shut down there will be no memory leak warning.

Versioning Control and TBA


TrustBuilder Administration is not able to version your files, but this gives you the ability to use your own system.

As files are stored in the TBA home folder you can check-in your files from there.

A complete explanation of all systems is out of scope in this manual. Their are plenty of systems available like cvs, git and mercurial and can be combined with web based versioning systems like github, bitbucket, rhode etc.

When you first install TBA you have given a path to store it files.

This path can be edited from the Application screen which is visible in the navigation if you have the TBAGAdministrator role.

Each configuration has its own id (a number) represented by a directory.

# ls -l /opt/securit/tba/
total 24
drwxrwx---. 17 trustbuilder trustbuilder 4096 Apr 28 22:06 1
drwxrwx---. 25 trustbuilder trustbuilder 4096 Apr 28 22:04 35
drwxrwx---. 7 trustbuilder trustbuilder 4096 Apr 28 22:06 65
drwxrwx---. 25 trustbuilder trustbuilder 4096 Apr 29 15:27 66
drwxrwx---. 2 trustbuilder trustbuilder 4096 Feb 6 11:06 backup
drwxrwx---. 2 trustbuilder trustbuilder 4096 Apr 29 17:33 download 

In this example you can see the structure of a TBA with 4 configurations.

If you put this folder into your versioning system it will keep up with changes you make to all files including workflows, configuration and layout files.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.