5.0.1 Release Notes

Multiple warning messages are written to the server.log file when the Administration Console is started. It is safe to ignore these messages, some of which come from Seam classes, whilst others emanate from the console, indicating that the native component cannot be utilized to perform "discovery" operations.

Seam applications that include their own jbpm-jpdl.jar cannot use the provided jBPM-ESB integration (e.g. EsbNotifier) within a jBPM process to invoke ESB services that are hosted on the same server. This is due to classloader issues between the jBPM classes in the Seam application and the jBPM ESB Services.

There are three possible workarounds:

Refer to http://community.jboss.org/wiki/WorkaroundforSeamESBjBPMClassloadingIssue for more details of how to implement the second workaround.

Refer to http://community.jboss.org/wiki/JbossClassLoadingUseCases for more information about JBoss Class Loading.

Do not use the CXF technical preview with this release of the JBoss Enterprise SOA Platform. There has been no verification that it works. This is a preview of technology that provides support for the Apache CXF Web Services Stack.

In addition, if this technical preview is installed over the JBoss Enterprise SOA Platform server installation, the only fallback is to remove the SOA Platform completely and reinstall it from scratch.

The JBoss Native package for JBoss Enterprise Application Platform 5.0.0 is incompatible with the version of JBoss Web used in JBoss Enterprise SOA Platform 5.0.1. It will cause a JVM crash if used.

The jBPM Console will throw an exception when used to view a running process instance if the process definition used <fork> with <state>, <task> or <node async="true">.

To workaround this issue:

After making this change, the exception will not occur. The change does not affect functionality.

When you try to delete an ESB archive using the JON Console, the associated queues are not removed. They remain there, displaying as DOWN. Furthermore, if you try to delete these queues, an java.lang.IllegalStateException exception will occur.

When the server is started without the -c configuration switch, the profile named default is run. This is correct operation. Unfortunately, JON erroneously assumes that the production profile is run instead. JON also mistakenly assumes that the binding address is 0.0.0.0 if this has not been specified. To ensure that JON recognizes the default profile and binds to the correct address of 127.0.0.1, always use the -c and -b parameters. By doing so, JON will recognize the platform.

The ability to set up a message's individual processing time in JON for alerts does not work by default.

To work around this problem, firstly add the alerting feature (alertTimeThreshold and alertLengthThreshold) to the ESB deployment.

Having done so, you must then set up alerts for events filtered from the server log. Do this using the JON GUI.

Another issue with JON event logging is that the alerts mechanism may be delayed in starting for an indefinite period of time (possibly between fifteen and fifty minutes in some cases.) Whilst this delay is occurring, all JON Alerts are lost and will never be seen. (However, WARN messages, emanating from the SOA Platform Server Console, will be displayed in the EVENTS view.)

The JON plug-in's "Message Count" feature is incorrectly displaying a total number of messages for the ESB server, deployment, services and actions. It should actually be showing a rolling average.

jUDDI v3 uses Hibernate to create its database. This is different to the other ESB components, which use SQL scripts. This will be standardized in a future release.

When a new BusinessEntity with two names is published, the jUDDI Browser will display two businesses instead of one. This is because the user interface treats business names as strings and does not check them for uniqueness: the keys are the only unique identifiers.

There is an inconsistency between the FTP Gateway Listener and the FTP Notifier. The FTP Gateway Listener can accept non-alpha numeric characters whilst the FTP Notifier cannot. In the latter case, fields must be URL encoded. For instance, a # character must be entered as %23 to work in the Notifier. If you enter an illegal character, the Notifier will not work.

If SOAPProxy is configured to obtain the WSDL for a proxied service URL, a warning is logged, because the web service responds with a content length which either exceeds the limit or is unspecified.

When sending messages, the alerts will appear in the JMX Console. If you then log into the Administration Console, the java.lang.NullPointerException will appear once per minute. This exception only appears in the log; it is not visible in the JMX Console itself.

Note that you can use the JMX Console to display message alerts (jboss.esb:service=MessageAlerts). However, if the SOA Platform is monitored by JON or if the Administration Console has been accessed, message alerts will disappear when the Mbean view is refreshed because the MessageAlerts queue will be emptied.

Currently, the spring_aop quick start does not work with signed JARs. If you try to run ant deploy for this quick start, an org.jboss.deployers.client.spi.IncompleteDeploymentException will be thrown.

To work around this issue, replace the cglib JARs with unsigned versions.

When the Web Service proxy is used to invoke a one-way web service, it erroneously throws a run-time exception with HTTP Code 500, which is returned to the client together with a fault message. HTTP Code 500 is invalid in these situations as only Code 200 or 202 should ever be returned as the message was successfully transmitted to the ESB.

Currently, the default ESB handler class for the UDP Gateway is hard-coded into the XSD schema and cannot be changed or removed.

A web service's WSDL will be invalid and return a 404 error if the web service is deployed embedded within an ESB archive and the WAR does not contain the WEB-INF/jboss-web.xml file.

Currently, Scout creates a new AuthToken for every invocation that occurs through the BusinessQuery/BusinessLifecycle Managers. This results in rapid growth of the jUDDI authentication table.

A possibly way to work around this problem is to delete rows within certain timestamp parameters. For instance, all rows created more than ten minutes ago could be removed.

The default configuration for the SOA Platform includes the setting java.awt.headless set to true. This is required for the embedded console to function. However both the groovy_gateway Quickstart and the Hypersonic database manager require that this value be set to false and therefore will not work. If you require either of these items you can change this setting in run.conf, but doing this will disable the embedded console.

Currently, a new DocumentBuilder is created for each incoming message. This has a minor impact upon system performance.

The JBoss Enterprise SOA Platform 5.0.1 is not compatible with the JBoss Enterprise BRMS Platform 5.0.0. Use JBoss Enterprise BRMS Platform 5.0.1.

The BRP Rule Agent is designed to use a local cached copy of a rules package if the BRMS is offline. At the moment, when this happens, error messages are generated, which might confuse users. These messages can be ignored as the locally cached copy is, in fact, being used successfully.

Using the Full Publish option in the JBossAS view to republish a jboss-esb.xml project does not work.

To work around this issue, remove the project from the server and then add it again.

The ESB node properties for input/output variables grow larger than the jBPM panel when the latter is resized, to the point where the user must scroll left to see all of the buttons.

To work around this problem, click on a different node on the jBPM panel and then click back on the ESB Service node. Next, click on the input/output subpanel and it will be the correct size again.

The ESB examples packaged with JBoss Developer Studio 3.0 do not work correctly with JBoss Enterprise SOA Platform 5.0.