5.3.1 Release Notes

There is an issue with VFS caching and the deployment of non-core Camel components where the server has been running for more than thirty minutes. After the cache lifetime expires (30 minutes), if you deploy a non-core Camel component, an error is thrown. To work around this, deploy your application before starting the server or before this 30 minute limit, or raise the boss.vfs.cache.TimedPolicyCaching.lifetime property to a higher value. (No issue is present if you deploy a non-core Camel component before booting the server, or before the cache lifetime expires.)

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

A camel_esbschedule quickstart has been added to demonstrate the scheduling feature of CamelGateway.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

The jBPM5 installation instructions (README.TXT) did not explain how to validate the installation of jBPM5. Users would not know if jBPM5 was installed correctly. The business-central URL is now mentioned in the installation instructions as a way of validating the installation. A link has also been added to the jBPM5 console to aid users who have installed the jBPM5 integration and the BRMS-P deployable. Users will now be able to validate their installation.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Previously, there was no easy mechanism to allow a source specific query to be submitted to the runtime engine. Users needed to resort to user defined functions which can be unnecessarily complex. Source specific queries (or "native queries") can now be set in Teiid Designer. The runtime engine will then use this native query as an inline view instead of the respective table name within a FROM clause.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Issues arose from using jBPM with MS SQL Server 2005. When using these together, jBPM would experience deadlocks. This has been addressed through a revision of the mssql-ds.xml file. As a result, these deadlocks no longer occur.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

When using the JBoss ESB, a NullPointerException would occur at start-up in certain instances. This happened when a user uncommented GenericPipelineInterceptors in the jbossesb-properties.xml file. This has since been resolved. As such, this exception no longer occurs.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Users have been experiencing deadlocks in JBPM due to a missing index. Deadlocks are now avoided with the addition of a new index according to the following: # the foreign key constraint (already present in jBPM ddl script): alter table JBPM_TASKINSTANCE add constraint FK_TSKINS_PRCINS foreign key (PROCINST_) references JBPM_PROCESSINSTANCE; # new index to add to the schema: create index IDX_TASKINST_PRCINS on JBPM_TASKINSTANCE (PROCINST_);

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

The Javadocs were not included for the jBPM5 integration. Developers did not have the Javadoc to refer to for development purposes. The Javadocs are now included so developers have them available for reference.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Users experienced problems when specifying an endpoint URL while using the SOAPProcessor with HTTP Gateway. After setting the rewrite-endpoint-url to "false", the URL would persistently be overwritten and replaced with the original JBoss ESB URL. This was due to the Publisher not initialising with the Gateway. This has been resolved in the current release.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

The upgrade to jUDDI 3.1.4 adds additional tables in order to support digital signatures. The files: add-juddi-tables.*.txt provided in the distribution contain the SQL commands that will create the additional tables when upgrading from SOA-P 5.3.0 to SOA-P 5.3.1.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

SyncServiceInvoker sets the ReplyTo and FaultTo headers of the Call to null and they remain as null unless an Exception is thrown, in which case they will be set back to their original values. Now the ReplyTo and FaultTo headers also retain their original values when the process method succeeds, as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

When a task had more than 10 variables and you viewed task variables in jBPM Console, the view didn't limit results to 10 rows. When the "Next" link was selected, it threw an IllegalArgumentException. Results are now displayed as expected and no IllegalArgumentException is encountered.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

The modifySQL method in ODBCServerRemoteImpl handled '::' in queries incorrectly, resulting in unexpected results. Users have had to escape each of the colons to achieve the desired behavior. The modifySQL has been modified to identify occurrences of '::' correctly, so there is no longer a need to escape the colons in queries to achieve the expected behavior.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Users were experiencing difficulties upon using jUDDI with certain directories. Directories containing spaces in their names were not loading properly. This has been patched for the current release. Directories with spaced names now appear as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

In previous releases, an incorrect error would be displayed when using the JBoss ESB pipeline with SOAPProcessor actions to call a Web Service. If the wrapped web service returned a soap fault and HTTP response code 500, the HTTP Provider Gateway returned a response code 200 instead of the expected 500 response. This has been patched in the current release. Users will see the correct code 500.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

The soapui-1.7.1.jar is not included in the jboss-as/server/configuration/deployers/esb.deployer/lib/ directory resulting in a ClassNotFoundException. To workaround this issue, the user can add the JAR file to this directory manually. Manual instructions: Copy the soapui-1.7.1.jar from jboss-as/server/configuration/deploy/soapui-client.sar/lib to jboss-as/server/configuration/deployers/esb.deployer/lib directory. Note: The platform with this modification has been tested only for the purpose of verifying issue BZ-881924.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Camel has been upgraded to version 2.10.2 for the JBoss ESB. This update fixes several of the bugs associated with older versions of Camel.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

FrameUtil.isProcedure does not check that projectNode != null. This means that a proc relational query using a table function or other source without an access node will fail with a NullPointerExcpetion. FrameUtil.isProcedure now checks that projectNode != null before proceeding and no such exception is experienced.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

Users are experiencing problems when updating on multi-source models. If you are using multi-source models, performing updates, and using the default PROP_TXN_AUTO_WRAP of DETECT, then try to explicitly set the transaction mode by using of the following methods: * local (START TRANSACTION or setAutoCommit(false) * global/XA * set autoCommitTxn=ON on the URL

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

If one of the jBPM variables was missing when mapping from jBPM to ESB an exception was thrown. Now if a jBPM variable is missing (has a null value), the user will receive a log warning, not an exception.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.1.

When SOAPClient is used and an HTTP 500 Error is encountered, SOA-P throws an Exception containing the HTTP 500 stack trace which is not handled by ActionProcessingPipeline, resulting in an uninformative message.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

There is an issue with the way in which AbstractBpm5Action is registering handlers when processes start. When a user closes a task via the console, a race condition is causing an exception to occur.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

When SOAPClient is used and an HTTP 500 Error is encountered, SOA-P throws an Exception containing the HTTP 500 stack trace which is not handled by ActionProcessingPipeline, resulting in an uninformative message.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

It is desired that integration with jUDDI be upgraded for jUDDI version 3.1.4.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

FileUtil.renameTo(..) returns true even if it fails to rename the file. As a result, when a file that is locked by another process is picked up by the SOA platform, and the rename fails, an error is logged even though the file is processed successfully on the next attempt (when the lock is gone).

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

Users were finding that rules that used to work now result in Exceptions. To fix, it is suggested that the source code should be updated to use a new class instance directly, rather than via a declared constant.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

Our product no longer allows the use of default values in the mapping from ESB to jBPM variables (esbToBpmVars).

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

If a jBPM3 process is deployed using the ant task and the server cannot be reached, a value of "0" will be returned instead of an error message. If you are trying to connect to a server and receive this value, check to make sure that the server is available before redeploying.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

The HTTP gateway would return an invalid, empty WSDL document in certain circumstances. It was invalid because it was not in the correct namespace. Furthermore, the http-gateway should not return a WSDL document by default since it may be used with more than just SOAP.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

When creating a new jBPM3 project, JBDS should provide the option to go into the jBPM jPDL perspective to be consistent with the behavior when creating other types of projects. Currently, when creating a new jBPM3 project, all that happens is that the project is created.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

If the JBoss Enterprise SOA Platform is installed into a directory which has a space in its name then the ESB archive cannot be deployed as a null-pointer exception is thrown. To work around this issue, add "-Dorg.jboss.net.protocol.file.useURI=false" to your start-up script.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

The output of JNDI View MBean, invoked through jmx-console, renders incorrectly. This is because, in the HTML source code, HTMNL tags are encoded with < and >, so they do not displayed properly in browsers.

This behavior persists in JBoss Enterprise SOA Platform 5.3.1.

Java 7 is now supported.