The Apache CXF installer modifies the jboss-as/common/lib/ directory and the included server profiles of all, default, production, standard, and web. Any other server profiles that have been added will not be affected by the installer and will be incompatible with the common server configuration. To create a custom server profile, run the installer first, and then create the profile by creating a copy of one of the supported profiles (all, default, or production).

Backwards compatibility of binary JBoss Rules packages can not be guaranteed between versions. It is important that both client and server applications are using the same version to ensure serialization compatibility between them. When upgrading from one version to another it will be necessary to recompile binary packages from the old version for the version being upgraded to.

Importing an Microsoft Excel spreadsheet into in a Knowledge Base will cause an exception to be thrown ( StringIndexOutOfBoundsException ) if the spreadsheet was created in Excel 95 or earlier. This is because of an issue in the JXL library which is used to handle these files. This can be worked around by opening and saving the spreadsheet in Microsoft Excel 97 or greater or with OpenOffice.org Calc.

This will be fixed in a future release.

In JBoss Enterprise SOA Platform 5.0.0 or greater, the fragment filter is bypassed when the Smooks configuration only contains a single XSLT that is applied to the root fragment. In this situation the XSLT is applied directly. This is done for performance reasons.

This behavior can be disabled by adding a parameter called enableFilterBypass and setting it to false.

<param name="enableFilterBypass">false</param>

The jUDDI Console does not prevent users from attempting to delete accounts that they should not be able to. The interface makes it seem that any user can delete the root, uddi, and esbpublisher admin accounts in the jUDDI console but the accounts will not be deleted unless they actually have the correct permissions to do so. Also if the root user attempts to delete itself then an exception (UndeclaredThrowableException) is thrown. No permanent harm is caused and the display of the console is restored after a server restart.

If no UDDI subscriptions have been defined then the jUDDI Console's Subscriptions page will be blank except for four icons that appear to not work. The buttons are not active until at least one subscription has been defined.

A JBoss Rules project created with JBoss Developer Studio 3 for JBoss Enterprise SOA Platform 4.3 required that the JAR files mvel2-2.0.12.jar and xstream-1.2.2.jar were added to the classpath. This is no longer necessary because JBoss Enterprise SOA Platform 5 now includes these files in each server profile. They can be found in $SOA_ROOT/server/$PROFILE/deployers/esb.deployer/lib/.

The JBoss Enterprise SOA Platform 5.0 requires that JAR files in ESB archives are placed in either the root directory of the archive, the /jars directory, or the /lib directory. Previous versions did not have this restriction.

Logging has changed in this release. Do not copy your customized logging definitions over from past releases or you may encounter performance problems.

Refer to https://jira.jboss.org/jira/browse/SOA-1754 to learn more about this issue.

Refer to the EAP Administration and Configuration Guide at http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/ to learn how logging has changed.

The HttpResponse class in 5.0 is not backwards compatible with previous versions because of changes made to unify the ESB HTTP classes. This was done as a part of the new servlet-based HTTP gateway.

Applications and services that use HttpResponse will have to be updated before they can be deployed on JBoss Enterprise SOA Platform 5.0. The changes required are summarized in Table 2, “Refactoring requirements for HttpResponse”.

The JBoss Enterprise SOA Platform creates new databases for its components to use. Databases from community versions have not been tested and may not work. If the use of existing databases is needed, then contact Red Hat JBoss Support for advice.

Groovy has undergone a major update from version 1.0 to 1.5.4. Be aware that many changes were made to the language and, whilst most scripts will still work, you may find that some will need minor work. Ensure that you test them as part of your migration process. See http://groovy.codehaus.org/Documentation for more information.

Smooks no longer supports the addToList option. Update any configurations that rely upon this option so that they instead use the newer <jb:bean> configuration namespace, which can handle lists. See the "Java Binding" chapter in the Smooks User Guide for more information.

The non-secured version of the jBPM console is no longer needed for process deployment because the jBPM console now supports authentication for deployment. The process deployer is available at http://localhost:8080/gpd-deployer/ . This replaces the deployers from previous versions, http://localhost:8080/app/upload and http://localhost:8080/upload .

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.

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.

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.

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.

Four JBoss Rules related fixes have been ported from JBoss Enterprise BRMS Platform. These issues are:

These issues have all been fixed.

FIXED: JBoss Rules Session insert was throwing an unexpected exception (ConcurrentModificationException) in multithreading enviroments.

RuleFlow would sometimes not execute correctly inside of the BusinessRulesProcessor ESB action. This was because it was running in a stateless session instead of a stateful session as would be normally be expected. The stateless session handling code has been updated to handle this type of scenario better.

A java.lang.ClassCastException occurred if the user deployed the security_saml quick start with CXF enabled. This was caused by an error in a build file which lead to the class being found on deployment but not on the subsequent run test. To fix this problem, the picketlink-sts.war file has been updated in the quick start. As a result, the exception no longer occurs.

The JBossESB namespace XSD URL has been changed for this release. The jboss-esb.xml files in the JBossESB product quickstarts have been updated to reference the current namespace definition. The correct namespace is required when using JBoss Developer Studio or autocompletion does not work.

The correct XSD URL is now: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.1.0.xsd

Non-ESB web-service related quick starts would not work with CXF. They would fail upon deployment. The code now checks the profile against which they are to be run and, if jbossws-native is absent, produces an informative error message instead.

The instructions in the wsmq_router QS readme file contained an unnecessary step for creating a datasource that is not currently used. This step has been removed from the file. As a result, the instructions are simpler and more relevant.

A dead-lock could occur in the JCA layer, when the JBossTS transaction reaper aborted a transaction. This was due to an issue with mutli-threaded access. The code has been fixed and, as a result, this dead-lock no longer occurs.

The jboss-esb.xml file was not being validated against the appropriate schema. This problem was caused by the order of the static initialisers within the ModelParser. It has now been fixed so that it is validated correctly. Note that the setting can be overridden by using the jbossesb-properties.xml file's org.jboss.soa.esb.deployment.schema.validation property.

A registry exception occurred when the server was started. This was caused by a concurrecy bug in JUDDI. A code fix has been applied. As a result, this exception no longer occurs.

The bean configuration property names have been changed so that they now adhere to JavaBeans conventions. For example, property names of the form:

isTransactionEnabled

are now named:

transactionEnabled

They are still backwards-compatible, so names in the previous format can still be used.

In JBoss Developer Studio, BPEL projects could not be associated with the SOA runtime, which appeared disabled even when usable. Users were then incorrectly prompted to uninstall one of the current project facets. This issue has been resolved by adding the BPEL facet ID to JBoss Developer Studio, allowing users to select SOA as the targeted runtime.

Because the serialised format can change depending on the version of JBoss Rules and whether the contents included encrypted payloads, the generated package has been removed. It is now created automatically. As a result, compatibility issues no longer arise.

The "Database Configuration" section of the ESB Administration Guide contained a reference to the ESB Management Console, which is not included in the SOA 5 product line. This section has been updated, and is now clearer and more relevant.

The opensso-1.0.ear in the opensso ESB quickstart did not deploy. This occurred for several reasons: firstly, because the application.xml file contained a Byte Order Marker (BOM), which could not be parsed by the deployer; and secondly, because jboss-aop.xml contained an incorrect namespace definition. These errors have been removed from the configuration files. Additionally, the jsr173_api.jar is no longer included in the WAR file, and the quickstart now deploys without error.

JBoss SOA Platform ships with headless mode enabled. However, some quickstarts require that this mode be disabled in order to run. Refer to the Configuration section of the SOA Getting Started Guide for instructions on disabling headless mode in order to run these quickstarts.

It is not recommended to run JBoss SOA Platform in a production environment with headless mode disabled.

When using the JBDS to publish to ModeShape, there is now an option that allows the user to specify the "workspacepath". This path is used by the server when determining what to sequence.

A race in the JBoss Messaging code was triggered when the JCA layer attempted to close down a messaging inflow deployment. This caused an exception of type IllegalStateException during the commit on the transaction boundary. Several JBoss Messaging patches were back-ported to fix this issue.

The SOAPProxyWsdlLoader initialised the TARGET_HOST_URL while it extracted the HTTP client configuration. This resulted in host/port information being retained for all subsequent WSDL queries, irrespective of the values specified in subsequent URLs. The code in the SOAPProxyWsdlLoader file has been modified to correct this problem. As a result, the values in subsequent URLs are now recognised.

A null-pointer exception occurred when the user added an activity to an onAlarm scope. This was caused by a bug in ReconciliationHelper.java. The code has been rectified and, as a result, the user can now add an activity to that scope without encountering an exception.

Missing WSDL imports were marked by the validator as warnings. This is not accurate, since the process does not deploy when the process file declares an import to a non-existent WSLD. The validator now marks missing WSDL imports more accurately as errors.

If the user created a new deployment descriptor, modified it, and then deleted the file from the project, the ODE deployment descriptor editor remained open. Even if a new deployment descriptor was then created, the editor did not refresh to display its contents. The ProcessPage.java file has been modified so that the editor closes when a deployment descriptor is deleted.

An error appeared in stdout if the Administration Console was run under the default deployment. The message stated that the "Plugin [Platyform] at [jndi:/localhost/admin-console/plugins/rhq-platform-plugin.jar] could not be loaded and will therefore not be deployed." This occurred because the JAR file did not contain signing information. The JAR file has been modified appropriately, and the error no longer appears in the log.

When an ESB service entity was viewed with the Admin Console, the same description was shown for all ESB services in a service deployment. The code that gathered the descriptions has been modified so that the correct descriptions are shown.

There was no way to set the polling frequency for the Camel HTTP component. The default polling frequency was too high, producing a lot of messages. Support for scheduling has now been added to the Camel Gateway.

The MessageSucker migrates messages between different members of a cluster. It consumes from a remote queue, from which it receives messages destined for the queue on the local cluster member. If it stalls, failed messages are not redelivered, and remain in the database. JBoss Messaging has been modified so that a stall triggers message redelivery.

Exception handling has been improved. The rollback() method now catches and returns any exception thrown while rolling back the transaction and logs it. Previously, if the commit() method threw an exception in DbPersistenceService.endTransaction(), rollback() was called and then, if rollback() also threw an exception, a client application would receive it, which was not optimal behaviour.

A sub-set of web-service quick starts failed to compile if CXF was installed on the machine. This was caused by the inclusion of the jaxws-rt/tools JARs within soap.esb file. A missing file was added to support CXF integration. As a result, the quick starts now compile correctly.

The jUDDI schema specified an invalid type for the WSDL in the uddi_v3replication.xsl file of the juddiv3.war. The WSDL type has been corrected.

The DB2 schema tool checked the lib directory for the db2jcc.jar. However, the correct name for the jar in this location is db2jcc4.jar. The check has been updated.

Upon server start, several "could not create directory" errors were logged when attempting to create the esbwarfiles directory. The logged error was inaccurate, as the directory already existed. A check has been added to handle an already created esbwarfiles directory, so that this error is only logged when the directory does not exist and cannot be created.

The jUDDI client could not retrieve services with the JAXWSTransport. Any attempt resulted in an exception of type TransportException. This occurred because the service names specified in the WSDL did not match those in the JAXWSTransport. The WSDL has been updated to match the JAXWSTransport.

Truststore configuration in HttpClientFactory did not work correctly. There were two issues. Firstly, the defined protocol was never used, meaning that the socket factory always used the factory associated with the default Protocol instance. And secondly, the protocol socket factory builder were unable to retrieve encrypted passwords from a file. Both of these issues have been resolved and Truststore configuration works correctly in HttpClientfactory.

If authentication information was stored for SOAPProxy, clients without authentication information could not invoke the service, even when the clientCredentialsRequired property was set to false. Authentication is no longer required when this property is false, even if authentication information is stored.

Using the JBoss Rules ESB service (jbrules.esb) from an EJB would not work for any EJB deployed after the first. This was because the classes were loaded using the jbrules.esb classloader instead of the context classloader. Because the class is cached between deployments, calls by subsequent deployments would be using the wrong classloader. This has been resolved by ensuring that all deployments would attempt to use the context class loader first.

When a mail from header was set in jbpm.cfg.xml, the value of the jbpm.mail.from.address property was not used in the header. This has been corrected, and the header can now be set in jbpm.cfg.xml as expected.

The dispatcher thread from jBPM 4 has been backported to this release. This fixes a race condition that appeared in in multiple JobExecutor threads which was caused by locking issues specific to MySQL 5.0. These locking issues do not affect later MySQL versions. As a result of this fix, users will no longer encounter race conditions in this scenario if using MySQL.

The default JVM memory settings in run.conf (and run.conf.bat) have been updated in this release. PermSize is no longer set, and MaxPermSize is set to 256 megabytes. This provides a more consistent server behavior on different platforms.

The JBossTS TransactionReaper contained a bug which caused it to execute continuously when it was running in dynamic mode, rather than pausing between runs. This caused performance degradation. To fix this issue, JBossTS was updated. As a result, the Reaper now pauses between runs, leading to better performance.

The top-level SOA Platform 5.1 page, displayed at http://localhost:8080/ has been enhanced to display the URL for not only the ESB project but for Teiid, Drools and jBPM as well. As a result, users can now quickly access these project sites.

The process logs that recorded changes in process instances within Timer.Execute were not being saved in the database. To fix this problem, a code change has been made to ExecuteTimerCommand.java. As a result, the JBPM_LOG table now shows entries for the variable modification and transitions from the timer.

The SOA Platform's InVM invocation relied on BusHolder but this was not added until a later version of the JBossWS CXF integration. To rectify this, it was necessary to extend the JBossWS configuration to support InVM invocations. This means that the the ESB code can then choose whether to create a ServletControllerExt using the BusHolder or reference the instance stored in the extension 'bag'.

The CXF integration required an XML catalogue to be specified as it would otherwise try to resolve the schemas remotely. To fix this problem, a jax-ws catalog for juddi webservices has been added.

JMS messages could be lost and actions could be terminated prematurely during shut down. This was because when the doStop method was called it set the state to STOPPING and immediately terminated the executor thread (MessageAwareListener.java) irrespective of whether the thread was processing anything or not. To fix this problem, a change has been made to the MessageAwareListener code. As a result, messages will not be lost when the software is shutting down.

Web Service-related quick starts failed to deploy when the Web Service stack was switched to CXF. This was because the 'assert-ws-available' targetwas searching for the cxf-rt-core.jar in the {org.jboss.esb.server.home}/common/lib/ directory instead of in the {org.jboss.esb.server.home}/client/ directory, which is its correct location. To fix this problem, the check has been removed. As a result, the Web Service quick starts now deploy.

Using the Schema Tool to move org.jboss.internal.soa.esb.dependencies.DatabaseInitializer from deploy/jbossesb-registry.sar/juddi-ds.xml into deploy/jbossesb-registry.sar/META-INF/juddi-service.xml caused an error when the user deployed the BPEL engine. To fix this problem, a new build.xml file has been supplied. This file does not create a separate /deploy/jbossesb-registry.sar/META-INF/juddi-service.xml file but merges the new prototype juddi-service.xml into /deploy/jbossesb-registry.sar/juddi-ds.xml. As a result, uers can now deploy the BPEL engine after having run the Schema Tool.

The SOA overlay for forms-based authentication was not applied correctly to the WS-CXF console. This caused the console to fall back on basic authentication. A code fix has been applied, meaning that forms-based authentication now works correctly for that console.

The queue definition files pertaining to legacy JBoss message queuing have been removed from the quick starts. This has been done so as to avoid potential user confusion.

The message composer's default NullPayloadHandling has been changed to NONE. Previously, in both the HttpMessageComposer and the JBossRemotingMessageComposer.it was set to LOG.

After importing a source package into Eclipse and adding an ESB server run-time, the following error would appear:

Description Resource Path Location Type

The method setOutgoingRunAs(RunAs) in the type SecurityContext is not applicable for the arguments (RunAsIdentity) JBossASContextPropagator.java /JBossESB/rosetta/src/org/jboss/internal/soa/esb/services/security line 262 Java Problem

To fix this problem, the .class-path has been updated to reference the AS5 JARs as they extend the functionality of the AS4 versions. As a result, the error will no longer occur.

The MessageCounter MBean was reporting the bytes processed count incorrectly. This was due to a SOA bug that has now been rectified. As a result, the MessageCounter MBean now reports the number of bytes processed correctly.

If a SOAPProxy Service' proxy URL was unreachable, the server would hang. A series of code fixes in the routing Java classes have rectified this problem so that the server no longer hangs in this situation.

Any ReplyTo EPR which was present on incoming messages to the Aggregator was not being propagated to the aggregated message. As a result it was necessary to explicitly set the EPR using a pipeline action after the aggregator. Now, if the same EPR is present on each of the incoming messages to the aggregator then that EPR will be propagated to the aggregated message.

If the configuration was set in certain ways, the custom retry handler was not picked up. This was due to a bug in both POSTHttpMethodFactory and GETHttpMethodFactory, whereby the setConfiguration(ConfigTree):void method was not set in the HttpMethod's HttpMethodParams. A task has been added to AbstractHttpMethodFactory to correctly extract the parameter and instantiate the handler. Note that the retry handler is configured by specifying the org.jboss.soa.esb.actions.routing.http.routingHandler parameter on the action. The value of this parameter must be the name of a class which implements HttpMethodRetryHandler and has a public, no-arg constructor.

The soapui SoapClient would, in some situations, incorrectly identify elements within the soap response as a collection and append an index to the name, e.g. [0]. This has been corrected and it no longer does this.

The SOAPClient always mapped null objects to an empty element. This has been changed so you also have the option to use the xsi:nil attribute if appropriate.

The bpm_orchestration2 quickstart used to demonstrate fork and join operations in the business process could result in contention between the forked actions. This was because the forked actions were all configured to update the same process variable. This quickstart has been updated so that the forks use different variables. This prevents the contention with actions after the join responsible for merging the data

The MessageMulticaster created an aggregation identifier and stored this value in message properties. This caused problems when used in conjunction with the InVM transport because, when it was sent to multiple services all services would see the same properties and, depending on timing, potentially see the same aggregation identifier. To fix this problem, aggregation value is now stored in the message context as this section is always duplicated, rather than shared, when a reference is created.

The SOA Platform shipped with JackRabbit and JCR 1.0 API. As these are unsupported on this platform, they have been removed.

WISE was loading the Smooks configuration for populating the Java classes, before the classes actually existed on the class-path. This caused an issue for the name-space configuration which needs to be able to load the class instance to perform some checks. As the classes did not yet exist, it would throw an exception.

To fix this problem, a modification was made to the WISE SmooksMapper class and the Smooks instance creation was moved out of the constructor and into the "applyMapping" method. The classes are already generated by the time this is run, so the exception no longer occurs.

The "Customer Portal" link has been renamed the Red Hat Customer Portal on the top-level web application (http://localhost:8080/).

The ESB Programmers' Guide documentation on exception processing behaviour has been updated to reflect that the SOAPClient throws an ActionProcessingException when a web service that is being called generates a SOAP fault.

SoapUIClientService transformations targeted at the #document fragment were being lost because the SoapUIClientService already held a reference to the old DOM Document root element. To fix this issue, an change has been made to the SoapUIClientService.buildSOAPMessage() method where it calls Smooks. As a result, the transformations are no longer lost.

An object path was being converted to a real object twice because of conflicting calls to the Object Mapper. When the object on the object path was not a String an exception was thrown. In other cases, routing would not work. A series of code changes have been applied so that the duplication no longer occur, eliminating the problems this caused.

There was a bug in both POSTHttpMethodFactory and GETHttpMethodFactory, in which the setConfiguration(ConfigTree):void method's http-client-properties were not set into the HttpMethod's HttpMethodParams. This meant that any custom retry handlers were ignored. This bug has now been rectified so that any property that starts with "http.method." is set into HttpMethodParams. As a result, custom retry handlers are now detected correctly.

The messages' "from" attribute was not being auto-populated with the "mail.from" property. Instead, the message.setFrom() method had to be called explicitly. A testFrom method has been added to the MailTest case. It ensures that the "from" attribute is set correctly.

The validation process for the HTTP header was stringently checking that it was "not empty." However, there are occasions when it can, validly, be empty. To account for this, the condition has been relaxed so that it now checks for "not null" instead.

The /http_gateway/readme.txt file erroneously referred to "http-listener" instead of "http-gateway" causing confusion for users. It has been amended.

The JBossESB namespace XSD URL has been changed for this release. The jboss-esb.xml files in the JBossESB project quickstarts have been updated to reference the current namespace definition. The correct namespace is required when using JBoss Developer Studio or autocompletion does not work.

The correct XSD URL is now: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.1.0.xsd

The SOAPClient's OGNL utility was not mapping collections correctly from SOAP responses. This has been fixed, and now works correctly.

The ESB depends on the message's replyTo to know where it has to send a RequestResponse service reply. However, the Aggregator action made no attempt to preserve the replyTo when it created an aggregate message for a series. To resolve this issue, it now only maps an end-point reference onto the aggregated message if all of the messages attached to the aggregated message have the same EPR.

In most cases, I would think the replyTo on the aggregated messages would be the same, so adding it onto the resulting aggregated message would seem like a good idea. Otherwise, it has to be handled manually in the assembler action.

The user could not make a jms-message-filter with a destination type of "TOPIC" a durable subscriber to a topic. This is actually configured via the jms-listener which has been changed to allow for this configuration option. As a result, users can now make these durable topic subscribers.

The soapui client failed to load multiple interfaces if authentication was required. This was because only the last interface contained the WSDL context that was loaded using the httpclient, and it is this httpclient that contained the authentication information. By doing so, it forced prior interfaces to reload using the UrlWsdlLoader. The UrlWsdlLoader did not know about the authentication as it instantiates its own httpclient. To fix this problem, a JBoss AOP aspect was created. This intercepts calls to soapUI's WsdlContext$Loader.getWsdlLoader() method so that the EsbWsdlLoader is always returned. As a result, the soapui client can now load multiple interfaces, even if authentication is required

The ESB Programmer's Guide incorrectly asserted that not all the gateways used ServiceInvoker. All the gateways do now use ServiceInvoker and the documentation has been updated to reflect this.

The MBean attribute "StateString" that was previously available via the JMX console was no long present. This was because the SOA Platform is running on Application Server 5. As a result, users could not find out the ESB package's deployment state (such as "Started" or "Stopped") via the JMX Console. This feature has now been ported to Application Server 5 so it can be utilised again.

The SOAPProxy, SOAPClient and HttpRouter all use the Apache HTTP client to implement HTTP invocation. As the URLs for these actions are static, they always point to the same host. Previously, the values for the maximum total connections and maximum connections per host HTTP for each of these clients had to be set individually. Users can now set via a single parameter instead.

To improve jBPM performance, a form of caching has been added to the ActionProcessingPipeline. This was achieved by activating the caching registry interceptor and having its validity period default to the same as that for default registry cache if it is not specified.

A javax.jms.IllegalStateException was thrown when the SyncServiceInvoker was used to invoke a proxied service. This was because of poor tracking of XA sessions returned to the pool, leading to conflicts. To fix this issue, some code changes have been made so that the software now tracks session users, producers and consumers and the caching of XA sessions. As a result, this exception no longer occurs.

Support for a JBoss WebService/CXF stack has been added. Apache CXF is an open source web services framework.

jUDDI was failing to register some of the services received via GetSubscriptionResult. This has been fixed by an upgrade of jUDDI to version 3.0.2.

A signed manifest file has been added to the soa-5.1.0.zip archive that is available on the Customer Service Portal.. Customers should use this to check the integrity and source of the SOA-P5 jars on a per-file basis.

If the user deployed a JBoss ESB service for which the description attribute was set to "", an exception would occur when the service was registered in jUDDI if the Oracle10g database was being used. This was caused by a problem with jUDDI. To bypass this issue, the ESB has been changed. It now ensures that a service description is present.

The PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml configuration file included an example that used the JAX-WS transport to connect to the local UDDI registry. Using this example configuration caused the server to freeze at launch. The JAX-WS transport can only be used to connect to a remote UDDI registry because the required webservice endpoints are not available until after the server has finished launching.

The JAX-WS configuration example has been updated to replace the ${jboss.esb.bind.address}:8080 values with REMOTE_HOST:REMOTE_PORT. Using this configuration requires that the settings be edited to include the correct hostname and port for the remote UDDI registry.

The security service implementation used in the jUDDI console was unable to retrieve an authToken from a remote server that was defined in the client configuration file. This was due to a bug in jUDDI that was resolved by upgrading that component to a newer version. (Note that it is necessary to click the New Subscription button to show the configured nodes.)

If the user deployed an ESB via ant, concurrency issues could arise in the JON tree model in certain circumstances. This happened because the tree model was being updated by a separate thread. A code change has been made to fix this issue. As a result, users will no longer encounter these concurrency issues.

Setting HDScanner's scanEnabled attribute to true via XML caused an null-pointer exception because the setter logic relied on the fact that the class's create method had already been called. To fix this issues, a test case for the HDScanner has been added. As a result, users will no longer encounter this null-pointer exception.

If the user deleted a missing deployment, an exception occurred. This happened if the user launched a quick start, imported the SOA Platform into JON, removed the quick start (via ant undeploy) and then tried to remove it again via the JON console. To fix this problem, the software has been changed to catch NoSuchDeployment exceptions.

The deployment type could not be found in the JON Console. The entry in the Value field would state "nothing found." This has been fixed so that the deployment type is now displayed correctly.

Quick starts would fail with a javax.naming.NamingException: Failed to retrieve Naming interface for provider. This was due to a problem with the load generator. To fix this issue, the Groovy class-path has been changed to the exec class-path. As a result, quick starts will no longer fail with this problem.

Warning messages would always be displayed at start up if the JBoss Enterprise Application Platform native components were not installed. These messages do not appear now.

If a BusinessEntity which did not define any BusinessService objects was saved to jUDDI, a NullPointerException would be thrown as soon as a user attempted to view that BusinessEntity's properties in the jUDDI Console. This was due to a bug in the Console. A code change has been made and, as a result, the users will no longer encounter the NullPointerException in these circumstances.

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 recognises 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 recognise the platform.

Support for schema import/include has been added to SchemaValidationAction

An exception (java.lang.Exception) would occur if the user tried to run start, stop, create or destroy deployment operations from withing the ESB Statistics level.

In order to mitigate this problem, these operations are no longer available at this level.

JBoss Cache is now used in the cluster configuration of jBPM.

A new section has been added to the ESB Programmer Guide about creating custom gateways, Section 7.2.5. Creating Custom Gateways.

Support for the unwrap/wrap switch has been added to HttpRouter. This provides consistency in the API.