Once the WS Dispatch had been created for a service, it is reused for subsequent requests. However, even if a different endpoint reference was associated with a partner link, the endpoint reference previously initialized would be reused. In order to fix this issue, the software has been modified so that the dispatcher is now created for each external invocation. As a result, if an endpoint reference is assigned to a partner link, then it will now call that endpoint as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

In previous versions, an exception would appear when users attempted to retrieve a node's version history. A "PathNotFoundException" message would appear. As a result, users could not view the requested information.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

The incorrect host was used in the ESB binding service. The value of esbHost was set to jboss.bind.address instead of jboss.esb.bind.address.This caused a problem when the server was started with the -b 0.0.0.0 option,(allowing it to bind to any interface). To fix this problem, the name was changed and binding now works as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

In the juddi-client's org/apache/juddi/v3/client/mapping/WSDL2UDDI.java file, the wrong tModelKey key type was specified. It was set to 'uddi:uddi-org:types', when it should have been 'uddi:uddi.org:categorization:types'. The name has been corrected so the tModel named uddi-org will now work as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

The ESB source contained activemq jars that had become outdated and are no longer supported. These jars have now been removed. As a result, the activemq Java Message Service provider is no longer available for use.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When a user tried to deploy an ESB archive via either the Admin Console or JON, they were presented with legacy SOA 4.x options that were no longer relevant and some needed options were missing. To fix this issue, new options for farm and exploded archives have been added. As a result, users can now deploy these via the consoles and the right information will be asked of them by the software.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

The Wise SOAPClient did not map all of the parameters for wrapped-style web services to SOAP requests. An additional XML attribute was needed. The software has now been changed so that they map correctly.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Problems would arise when attempting to access the BPEL Console at http://servername:8080/bpel-console/ if Oracle 11G was the database. An exception would be thrown which read "Failed to execute query". This was solved by converting native SQL commands into HQL. It has been fixed in Riftsaw 2.3.2.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

A problem occurs when the user tries to deploy a service for the first time. When adding the remove-old-service attribute to the EPR, the service registration fails and a ServiceNotFoundException error is thrown. The registerEpr should be moved to prevent this from occurring.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

The org.jboss.soa.esb.services.security.auth.ws.BinarySecurityToken class has been made abstract, allowing users to implement Kerberos Token Profiles. The BinarySecurityToken has been made into an interface and is pluggable. To use, add a property to the security section of the jbossesb-properties.xml file containing your implementation class name.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Components which use messaging, including jBPM and the JBoss ESB, have startup issues when the user is employing HornetQ. These components do not work out-of-box when the server uses HornetQ as a messaging provider. This is caused by a missing guest user property in hornetq-users.properties and guest role in hornetq-roles.properties in each server configuration. To work around this, uncomment the default user or ensure all the components use secured access to the queues/topics.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

A bug was present in previous versions when users would attempt to route a message to a service using secured jms-jca-provider. If one service is called with jms security defined and uses jms-jca-provider, any subsequent call to a secured jms service uses outdated credentials. This has now been patched. As a result, the latest credentials will be applied when this service is invoked.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

There was a version conflict between the BRMS gwt-console-server.war and bpel-console.war/gwt-console-server.war. This resulted in a deployment error. This has been fixed in 5.3.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Users experienced problems when using the production process in SOA 5.2. This process was supposed to modify the run.conf scripts to include java.awt.headless and the DTMManager but failed to do so. The run.conf files have now been patched to resolve this. The production process should run as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Users need to specify the Camel gateway's URL in this format: irc:username@irc.server.com:6667/#channel. Unfortunately, the hash (#) symbol was being replaced with "%23". As a result, it could not connect. To fix this issue, the software has been changed so that unsafe characters are now decoded before being sent to Camel. As a result, it can now connect correctly.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

RecordRoute functionality has been added for messages and services. This places audit tracking information within the message context. Configure it as a filter within the jbossesb-properties.xml file.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Bpm5Processor does not map BPM parameters on SIGNAL_EVENT. This means that parameters added by users will be ignored. This is resolved by mapping the parameters and passing them in a signalEvent. As a result, user-defined parameters will now take affect.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When using BPEL, users were unable to create a new server runtime using the "New BPEL Project" wizard. When the "New Runtime" option was clicked, the selection tree was empty. This has now been patched. As such, the wizard now works as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

In SOA-P Platform 5.3, Apache Mina has been upgraded to version 2.0.1.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When using JDK7 to start JBoss SOA, the admin console would not launch due to a configuration problem. The software's jboss-logmanager has been patched to address this and the console now deploys correctly.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

In previous versions, BPELInvoke would block action processing if a BPEL process threw an exception or fault not defined on the WSDL interface. When an invoked BPEL process threw a fault, BPELInvoke blocked it regardless of its "abortOnFault" property. As a result, subsequent actions in the pipeline were never invoked. This has been fixed in 5.3.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When attempting to invoke a webservice with the Wise SOAPClient it will throw an exception. This is caused by a class error in JDK 7. A logmanager patch has been added to address this. As a result, users will no longer encounter this exception when invoking webservices via Wise.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When attempting to invoke a webservice via SOAPProcessor it will throw the exception. This is caused by a class error in JDK 7.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When attempting to use the auditing functionality of jbossesb-1.3.1.xsd, an error would occur. When using the .xsd on jboss-esb.xml files, a message would appear saying "Unsupported schema namespace". This was caused by a missing ModelSchemaParser property. The schema has now been added to the .xsd so users will not encounter this error.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

When using SerializableInstanceDbTest, an exception is thrown when an attempt is made to cast the retrieved ID (from the JBPM_BYTEARRAY table) to BigInteger.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

If you make a changes to a BPEL process, they will not deploy automatically after saving. This kind of incremental publishing is ignored by BPEL because it results in multiple deployments being triggered at once. Redeploying the process should result in a "full publish".

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

There were problems concerning the code completion feature in the Drools Rule Editor. When users attempted to use this feature on the second field constraint, the completion would fail to occur. This problem has now been addressed. The code completion feature works as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

There were problems concerning the completion for bind variables in the Drools Rule Editor. When attempting to use this feature, users would find that the completion was either incorrect or missing. This problem has now been addressed. As a result, the completion occurs as expected.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

An error occurred when attempting to use Groovy with the Schema tool. Running the Schema tool with Groovy version 1.8.x caused an error message to display. This has been patched. As a result, the two components will work together properly.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

There was a performance issue when creating an external web service client. Users who attempted to run a quickstart to accomplish this encountered performance problems. This was due to caching dispatcher issues. The problem has been addressed and performance should no longer be compromised in these instances.

This issue was resolved in JBoss Enterprise SOA Platform 5.3.0.

Attempting to switch perspectives when creating certain projects would not work. When creating new Teiid, jBPM and ESB projects, the user could only view them in the Seam perspective.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error occurred when the out-of-the-box SOA-P 5 server configuration was used. Upon deployment, a message displayed on the bottom of the screen reading "One or more ports have an invalid value".

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

There was an incorrect jBPM upload URL in previous versions. The URL originally reffererd to "/jbpm-console/upload" but it should have been "/gpd-deployer/upload". This problem has been fixed so "/gpd-deployer/upload" appears as the default value.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When using the BPEL editor, the user was unable to change the fixed value generated by variable initializer. This caused difficulties in creating processes.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error occurred when defining nodes in JBPM. If exception handlers were defined across multiple nodes, then only the first one was triggered during one execution.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

If you left a jBPM node in super-state mode, an exception was thrown. This resulted in users being unable to leave the node without also leaving the transition.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When using jms-provider, CLIENT_ACKNOWLEDGE mode was not accepted as a valid non-gateway listener. Although the message was retrieved by the JmsCourier and converted into an ESB message, the reference to the underlying JMS message was removed. Because of this, the message remained in the non-gateway queue after ESB service has been invoked.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

Users encountered a problem when using HornetQ with jBPM. When HornetQ was hot deployed, an error occurred causing jBPM to crash. This caused some processes to remain undeployed.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An exception was thrown when attempting to connect to the JMS server with HornetQ. The error occurred when the server's address was bound to 0.0.0.0. It was caused by the connectors' and acceptors' host being derived from the "jboss.bind.address" property.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

The soapUI SOAPClient does not map a requested Map object to a SOAP message template. This occurs when using OGNL with "xs:any" data types in the WSDL. Because of this, messages defined with the <xs:any> data type in the WSDL will not be sent.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When registering a BPEL process in a third-party UDDI registry with a SOAP protocol, an exception was thrown. A new patch has been added to address this so users can now register BPEL processes without encountering the problem.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

The JAXB Accessor Optimization disappears when using SOA-P supplied endpoints with signed jars. An exception is thrown and JAXB will fall back to using Reflection. As a result, optimization is lost.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error arises when using the BPEL editor to check validation. A variable initializer throws NPE when WSDL is renamed. As a result, users who rename objects within the BPEL editor may find that they do not validate.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

There is a problem when using HornetQ with the JBoss Messaging Client. The client's libraries are not transferred over after the user has switched to HornetQ. As a result, users cannot access these libraries in HornetQ. To work around this, users should add the JBM client libraries to the application itself.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When using jBPM, ProcessLogs (which represent changes of the process instance within Timer.Execute) are not saved in the database.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In some instances, the admin console shows an incorrect status of the ESB. After invoking the 'Stop deployment' operation on an ESB deployment using the admin-console, the status is still incorrectly displayed as 'UP'.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

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 behavior persists in JBoss Enterprise SOA Platform 5.3.0.

A problem occurs when attempting to generate content for messages using the variable initializer. Messages which use type attributes instead of elements fail to have their content rendered when the initializer is applied.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In JBossWS, using WS with attachments does not return information when DataHandler is used. The data will appear to have been successfully delivered to the service but will not return anything back.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In JBoss ESB, the binding service refers to "jboss.bind.address" instead of "jboss.esb.bind.address". Work around this by accessing the EsbPropertyServiceXSLTConfig property in conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml and inserting the code listed on this topic's Bugzilla page.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

JBossWS native adds additional namespaces upon output when documents have been added to the SOAP body. SOAPFactoryImpl forces namespace declarations to be added for all child elements which are not immediate descendants of the element declaring the namespaces.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

Users encounter problems when attempting to configure web service extensions using annotations. WS extensions could only be configured using an external XML file, not with the basic annotations which are used in other instances.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error occurs when using DLQ handling on JCA. This results in a duplicate redelivery to DLQ.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When sending a message in JBoss, the org.jboss.jms.server.container.SecurityAspect.check property is missing privileged blocks.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When a HornetQ security setting element configuration was delegated, it did not propagate its settings as expected.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

The BPEL web console does not work with Internet Explorer 7 and 8 on Windows 2003. As a workaround, please use the Mozilla Firefox browser in this environment instead.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

A problem arises when deploying ESB archives from the JON plugin. The deployment fails and a stacktrace is displayed.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

NotifyFiles will append a new line character at the end of a string when using the stringNotification() method. It does this if the string does not end with a valid character. This is a problem when the aim is to simply save some file content.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In some instances, users are unable to login to the jUDDI console. This occurs when a user attempts to log into the console without having the JBossAdmin role. As a result, they cannot log into the jUDDI console until the server is restarted, even once they have been assigned the JBossAdmin role.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error occurs when using deploying a scheduled-listener with invalid scheduleidref attribute. Upon deployment, a NullPointerException error will be displayed.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In previous versions of JBoss SOA, Apache's XMLBeans created integration problems. This caused exceptions on start-up when using the SOAPClient and more than one thread.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

Users encountered problems when attempting to create datasources using the MAC OS-X operating system. When using the web console to add a new datasource, an exemption was thrown upon clicking the "save" button.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

ESB applications are deployed at a context root corresponding the application name. (For example, app.esb is deployed at /app.) This causes problems when used with Maven since the artifacts are usually named app-1.x.x.esb. You can change the context root of an esb application through a descriptor instead of using the archive name.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

In failover situations, HornetQ triggers a redeployment of queues. (The affected queues are those deployed inside ESB archives.) However, this redeployment process results in "already deployed" exceptions.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

Undeploying ESB archives when using HornetQ can interfere with the delivery of messages. If you are sending messages to be processed by the gateway queue and undeploy the ESB before it has finished, the messages will not be sent automatically when you redeploy it.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

Normally, the SOAPProxy will change the service port addresses in WSDL (which are provided by a target Web service endpoint) from the default settings to the ESB's URL. However, if the target is a SOAP 1.2 service, the SOAPProxy fails to rewrite its SOAP 1.2 address location and the default URL remains in the WSDL instead. To work around this issue, use the SOAPProxy action's wsdlTransform property (found in the jboss-esb.xml file) to supplement the missing transformer for SOAP 1.2. See the bug ticket for a code sample.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

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.0.

Exception handling issues can arise after the SyncServiceInvoker fails. If an exception is thrown after the SyncServiceInvoker call, the error is not sent to the client. This can be resolved by setting a "FaultTo" EPR in a custom composer-class set on the service's FS-Provider.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

If the user changes the name of a .WAR deployment within an ESB archive, they cannot redeploy that archive because an exception will occur.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

An error arises when using the Gnome interface while editing a WDSL file. It triggers the Gnome shell to crash. As a result, edits to the WSDL will not be saved and the user may have to restart their computer to restore Gnome.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

When a BPEL process receives the second message for a receive activity before it receives the first one for a pick activity and the activities are correlated, the second message will no longer be required by any subsequent BPEL process instances with the same correlation identifiers.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

The Camel JCR gateway cannot perform a lookup for the ModeShape repository. When a user attempts to the use camel-jcr component, the deployment of the application fails because Camel can't lookup the ModeShape repository in Camel Context. As a result, the operation fails.

This behavior persists in JBoss Enterprise SOA Platform 5.3.0.

jBPM 5 functionality is now available.

Camel gateway is now fully supported.

Additional EDS translators and data sources are now supported.

HornetQ is now fully supported.

PicketLink (SAML) is now fully supported.