Release Notes 5.1.2

JBoss Enterprise Application Platform 5

for use with JBoss Enterprise Application Platform 5.1.2

Edition 5.1.2

Jared Morgan

Eva Kopalova

Russell Dickenson


These release notes contain important information related to JBoss Enterprise Application Platform 5.1.2 that may not be currently available in the product manuals. You should read these Release Notes in their entirety before installing JBoss Enterprise Application Platform 5.1.2.

Chapter 1. Introduction

These release notes contain important information related to JBoss Enterprise Application Platform 5.1.2. New features, issues fixed in this release, and other known issues are addressed here.

1.1. About JBoss Enterprise Application Platform

JBoss Enterprise Application Platform is the next evolutionary step in open source enterprise software. It is a powerful tool for developing rich, high performance Web 2.0 applications on a pure Java Platform.
By integrating best-of-breed open source frameworks such as JBoss Seam, Hibernate, CXF Web Services, JBoss Cache, and JBoss Messaging, the Platform takes advantage of innovations in the open source community. As well, JBoss Enterprise Application Platform is fully tested and supported by Red Hat, and is certified to work on many leading enterprise hardware and software products.

1.2. About this release

JBoss Enterprise Application Platform 5.1.2 is a minor release. Minor releases aggregate the contents of prior patches and Cumulative Patches (CPs), and may add functionality. Subsequent patches and Cumulative Patches assume the installation of the minor update that preceded them.
During the life cycle of a product's major version, Red Hat makes commercially reasonable efforts to maintain API-level compatibility across all minor releases and asynchronous patches, ensuring that, for example, JBoss Enterprise Application Platform 5.1.2 maintains API-level compatibility with JBoss Enterprise Application Platform 5.0.0, the initial release of JBoss Enterprise Application Platform 5. Possible exceptions to this rule include fixes addressing critical security issues.
PicketLink (offered to customers at v1.0.3 in JBoss Enterprise Application Platform 5.1.1) is graduating from Technology Preview to v2.0.1 GA.
With the release of JBoss Enterprise Application Platform 5.1.2, JBoss Enterprise Application Platform 5 customers should update to this release.
Refer to for more information about the JBoss Enterprise Middleware Product Update and Support Policy.

1.3. HornetQ

HornetQ is an optional JMS provider for the JBoss Application Platform which can be used in place of the default JBoss Messaging on a fresh installation (not upgrades). It will be made available through Red Hat Network (RHN) and Customer Portal asynchronously after the JBoss Enterprise Application Platform release, with its announcement via the same channels. With this release, HornetQ is graduating from Technology Preview to General Availability (GA) v2.2.10-Build2.


Do not install HornetQ packages (RPMs) if you have already set up JBoss Enterprise Application Platform 5.1.2 with JBoss Messaging or JBoss Enterprise Application Platform 5.1.1 with HornetQ TP. Attempts to install HornetQ on such an environment can cause package conflicts. Installation of HornetQ is available for a fresh installation only.

1.4. Excluded, Removed, or Deprecated Items


An item that has never featured in a product release but is otherwise part of one of the open source components of the product.
An item that will be removed from a future release, usually the next major version.
An item that was previously in a release of the product and is no longer included. Items will usually be deprecated before being removed.
JBoss Enterprise Application Platform 5.1.2 is a minor release. Compatibility is maintained throughout all minor releases with a major release. This means that all 5.x releases maintain binary compatibility with the initial release, 5.0.0.

1.4.1. Deprecated

Since the release of Enterprise Application Platform version 5.1.1 it's not possible to perform an upgrade from version 4.3. Specifically, updating to 5.1.1 from 4.3 using RPMs is not supported, and will result in platform failure.

1.4.2. Removed

The Java EE 5 Platform Specification required that Stax APIs be included with an implementation of the specification. The Stax APIs have since become part of Java Standard Edition 6. JBoss Enterprise Application Platform 5 is now built and distributed with Java SE 6 as a minimum SE requirement. To maintain compatibility with the Stax APIs, the Stax API jars are no longer packaged in the distribution.

Chapter 2. Installation Notes

2.1. Supported Configurations

An up-to-date matrix of compatible and certified configurations is available at Please refer to this list for information on tested and supported configurations.

2.2. Installing JBoss Enterprise Application Platform

Refer to the Installation Guide for instructions on installing and verifying the installation of the JBoss Enterprise Application Platform.

2.3. Default Startup Profile

The default startup profile is default, which is a base Java EE 5 server profile containing a default set of services. It contains the most frequently used services required to deploy a Java EE 5 application. It does not include the JAXR service, the IIOP service, or any of the clustering services.
The default profile is not intended for production use, or for running load, stress, availability or performance tests.

2.5. Product Support

If you find a problem with the product, you should raise a JBoss support case through the Customer Support Portal at

Chapter 3. New Features

New features of Enterprise Application Platform 5.1.2 are discussed by component.


The DOCTYPE of deploy\management\console-mgr.sar\web-console.war\WEB-INF\jboss-web.xml has been upgraded to "DTD Web Application 5.0" because it includes <security-role>-tags.


The JBoss Security Guide did not provide information on the SPNEGOLoginModule delivered with JBoss Enterprise Application Platform. A note on SPNEGO was added to the JBoss Security User Guide and the JBoss Negotiation User Guide was added to EAP documentation.


The default delay for message distribution has been changed from disabled to 60000 (1 minute). Any messages queued on a cluster node which are not consumed by a client within this period are automatically distributed to other nodes which do have matching consumers.


Splash screens can now be used via izpack. The following tag must be provided via the resources.xml inside the <xfragment> tag : <res id="splash" src="@{install.config.dir}/images/splash.png" />. The src is user configurable however the id must remain "splash". The splash size is directly proportional to the size of the image provided.
The installer has been improved so that at the end of a GUI installation you can save to a file the options chosen, then use this as input to the installer to re-create the exact installation. This option can be useful when you need to deploy the same EAP installation to multiple servers: e.g. cluster nodes, bulk deployment of new EAP servers. To use this feature:
  1. Complete the installation;
  2. At the final panel, click on "Generate an automatic installation script" and save the file;
  3. Use the installation script as follows: java -jar <path to jar> <path to generated file>, e.g. java -jar /home/tester/enterprise-installer.jar /home/tester/generatedfile


Seam could not be configured to add cache-control HTTP headers to the resources served by the Seam resource servlet. You can now configure Seam to automatically add the headers depending on the requested URI in components.xml.


PicketLink has graduated from a Technical Preview to being a fully supported release.


The deployment mechanism used by the MainDeployerMBean was rewritten for JBoss Enterprise Application Platform 5. As a result, some of the MainDeployerMBean operations returned no output or returned errors. The MainDeployerMBean methods were updated to restore the deployment functionality and can be invoked via the MBean server or via $JBOSS_HOME/bin/

Chapter 4. Fixed Issues

Issues fixed for Enterprise Application Platform 5.1.2 are listed by component.

Apache Server and Connectors

The apr and apr-util packages are no longer distributed as part of the Enterprise Application Platform. Use the same libraries distributed with the base operating system, Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. If you are performing a new installation of Enterprise Application Platform, you must ensure these packages are installed.


During distribution of the encryption key from the master node to each cluster member, the configured asym_provider and sym_provider were not used. These options are now set to be used when getting Ciphers.
In some circumstances, HA-JNDI could start processing requests before it was fully initialized, causing those requests to fail with a NullPointerException. This has now been resolved so that initialization is confirmed before processing begins.
The deployment of a HASingletonController as an MBean could fail if the MBean upon which it depended had not yet been started. To fix this issue the availability of dependent MBeans is first checked before deployment, resulting in reliable deployments of HASingletonController.
If there were concurrent calls to the UnifiedInvokerHAProxy function a NullPointerException error could occur when the last server was shut down. The issue was that the logic surrounding this function did not check if a target was available, resulting in the following error:
FATAL [org.jboss.invocation.unified.interfaces.UnifiedInvokerHAProxy] (TP-Processor242) Could not initialize UnifiedInvokerProxy.
The logic surrounding the proxy function has been changed so it first checks the availability of a target, preventing NPE errors.
When using the legacy eviction policy configuration format, if the wakeUpIntervalSeconds was not specified, the default value was set to 5000 seconds, not 5 seconds. This resulted is wakeUp intervals far longer than would be expected. This has now been resolved and the default is 5 seconds.
When creating a cache using the CacheJmxWrapper the ClusterConfig section was ignored, and a default JGroups configuration used. The cause of the problem was that the parser was ignoring the contents of the <ClusterConfig> section. This problem has been fixed and the whole of the cluster configuration file is read correctly.
Transaction stickiness has been enabled by default for EJB3 load balancing policies. This means that there's no need to create and configure separate load balancing policies to enable this feature.
It was not possible to specify default loadBalancePolicy for Clustered EJB3s because the EJBs already had @Clustered on them. This has been corrected and you can now edit $JBOSS_HOME/server/all/deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml and add properties such as RoundRobin, or specify fully qualified class names such as org.jboss.ha.client.loadbalance.RoundRobin The default for defaultLoadBalancePolicy is org.jboss.ha.client.loadbalance.RoundRobin if not specified. The default for defaultStickyLoadBalancePolicy is org.jboss.ha.client.loadbalance.FirstAvailable if not specified.
Fix an EJB3 clustered proxy bug where the clustered proxy factory implementation(s) do not take into account the overridden stackname and instead uses the default clustered client interceptor stack. This means that the @RemoteBinding(interceptorStack=...) annotations and the <interceptor-stack> tags in the jboss.xml file is ignored for clustered EJBs.
Deploying Web Applications (WARs) to a cluster farm via either the EAP Administration Console or JBoss Operations Network caused a NullPointerException on the joining node, similar to the following:
16:16:53,586 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey@27905a42[domain=default, server=default, name=farm] state=Configured mode=On Demand requiredState=Installed
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(
at org.jboss.ha.timestamp.TimestampDiscrepancyService.getTimestampDiscrepancy(
at org.jboss.profileservice.cluster.repository.DefaultSynchronizationPolicy.getTimestampDiscrepancy(
at org.jboss.profileservice.cluster.repository.DefaultSynchronizationPo
The cause of the error was incomplete internal data when checking time synchronisation between the deployer and deployee cluster nodes. This issue has now been fixed and deployment of WARs to cluster nodes is successful.
When two cluster nodes were merged after a split, only one of them should have continued to HASingletons. In fact both continued to run HASingletons, resulting in unreliable cluster operation. The cause was an error in the logic applied when node merged. This is now resolved and cluster merges now operate as expected.
Data loss could occur when calling cache.getNode in JBoss Cache with a cache loader configured for passivation. When cache.getNode loaded a passivated node, the data was not loaded, but it did trigger an eviction event. When eviction then passivated the node again, the data was overwritten. This issue has now been resolved and data loss no longer occurs in these circumstances.


Directly accessing pages of the JBoss Web Console resulted in an exception error. This has been fixed by ensuring that access to the web console is only available via its start page.
An exception occurred when creating a new Threshold Monitor via the JBoss Web Console. This has been fixed by checking that the DeploymentFileRepository MBean is available and if not, showing an error message.


The Standard Server Profiles section of the Administration and Configuration Guide stated incorrectly that the "All" profile is used if no profile is explicitly stated or configured. In fact the profile named "Default" is used in these circumstances. A new section Run the Application Server as a Service on Red Hat Enterprise Linux has also been added to the Installation Guide.
The "Workaround for Oracle" section of the Administration and Configuration Guide has been updated with the latest available information. If you are using Oracle, please check this section to see if it's relevant to your installation.
Instructions on upgrading EAP from 5.1.1 to 5.1.2 and later have been added to the Installation Guide.
In the Hibernate Core User Guide, a reference was made to an incorrect POM file. This reference has been updated in the documentation for the current release.
A bug in class org.jboss.mail.SessionObjectFactory caused only one mail service to ever be resolved, even if more than one service was configured and present in the JNDI tree. The class now resolves more than one mail service if one is configured.
A new section has been added to the HornetQ User Guide in the "Configuring Message-driven Beans" Section. The new section entitled "High Availability in Message-Driven Beans" explains the need for the "cluster" activation property in MDBs used in Clustered environments.
A node fails to read all its messages if disconnected from its database. This happens because the node fails to acknowledge messages on database disconnection. To avoid the problem, set the node parameter MaxRetry to a value greater than -1. You can set the attribute value in the MBeans PersistenceManager, PostOffice, and JMSUserManager in the file [database]-persistence-service.xml. The Messaging User Guide now contains details about the MaxRetry parameter, and how to configure it in conjunction with other related parameters.
The Administration and Configuration Guide has two new chapters: Enterprise Applications with EJB3 Services and Legacy EJB Support.
In the Using the Security Manager section of the Security Guide, the instructions for importing JBoss signing key were incorrect. The path to the keytool utility was listed as $JBOSS_HOME/bin/keytool but it should have been JAVA_HOME/bin/keytool. This section of the Guide has now been corrected.
Fencing for GFS2/SAN was not discussed anywhere in the HornetQ User Guide. While Fencing is required by HornetQ, the variety of ways to enable Fencing precludes specific discussion in the User Guide. To fix the issue, a new "Fencing" section was added to the "High Availability and Fail-over" Chapter. The section describes how to locate more information about configuring Fencing in other Red Hat documentation.
The HornetQ User Guide contained incorrect information on clients running inside a Java 5 Virtual Machine and referred to jars, which are no longer delivered in the Client Classpath chapter. The chapter now provides accurate information on these issues.
The Administration and Configuration Guide did not specify the ServerPeerID range (between 0 and 1023) required for JBoss Messaging in the Clustering Section of the guide. This caused problems with users specifying values outside of these ranges, which resulted in a java.lang.IllegalArgumentException. The fix adds an admonition to the "Initial Preparation" section detailing the node range required. Customer now know the range available when setting node ServerPeer IDs.
It was discovered that Windows customers were encountering problems when installing the platform using the Graphical Installer. Not correctly setting the JAVA_HOME environment variable before running the installer caused an warning message to display. The Installation Guide has been updated with a Task prerequisite of setting JAVA_HOME, with links to the appendix containing these instructions.


In the event of a transaction rollback during a timeout callback, the timeout callback must be retrieved as per spec EJB 3.1 FR 18.4.3. The container did not enlist the timer into the transaction and the timer could not be retrieved on rollback. Timer callback implementation has been changed to support running within transactions so that after the timeout callback is rolled back, the callback is retired by the service.
When messages were sent to a MDB which was not fully prepared to receive them, the MDB container would throw a DispatcherConnectException. Because this was a checked exception, and therefore ignored for determining transaction semantics, the transaction would commit and the messages would be acked without the MDB ever seeing the messages. The fix introduces new logic which checks that any exception is properly checked against the signature of the inflow method. Any invalid exception results in an UndeclaredThrowableException (/RuntimeException). When a RuntimeException is encountered during message inflow, the transaction is rolled back. Messages within that transaction are not acknowledged and retried at a later interval. The assumption is that the MDB is ready by that time to receive messages normally and thus normal operation resumes.
If an EJB jar deployment specifies a dependency and this dependency is restarted, the deployment or start of the EJB would fail with an IllegalStateException message similar to the following:
Caused by: java.lang.IllegalStateException: jboss.j2ee:ear=helloWorld.ear,jar=helloWorld-ejb.jar,name=HelloBean,service=EJB3 is already installed.
This was caused because the EJB's deployment was duplicated during the installation or start. To resolve this problem before upgrading to EAP 5.1.2, either redeploy the dependent EJB or restart the server. This problem has been fixed and this workaround is not required once you have upgraded.
A clustered EJB using @RemoteBinding(jndiBinding=...) or <remote-binding> incorrectly created a proxy in JNDI, then replaced it with the correct proxy. When the cluster membership changed, the wrong proxy's cluster member list was updated, so the EJB clients were not informed about the new member. The extra proxy is no longer created and removed. The cluster member list now updates correctly, allowing EJB calls to load balance and failover to the new nodes.

Embedded Jopr

When an application was deployed using the admin-console (Profile Service API), the application deployment was removed if it failed to start. The application could not be redeployed using the admin-console because the deployment was removed when deployment or startup failures occurred. The fix forces the Admin Console to allow application or resource deployment, even if the deployment fails to start. This functionality allows for situations where the user expects an application will not start due to dependency issues or HA singleton configuration, but still requires the deployment to remain on the EAP server.


When a HornetQ queue was hosted on a remote HornetQ broker, and was not defined on the local instance of the HornetQ broker, HornetQ activation was ignoring multiple forward-slash characters in JNDI queue paths. If a queue was specified as <queue name="jms/queue/myQueue">, HornetQ was interpreting this as <queue name="myQueue">. An MDB listening on a remote queue was unable to connect to the queue because the forward-slashes were removed from the queue name. This issue is now fixed as part of this release.
In a situation with clustered HornetQ instances where a cluster node has its journal disconnected - e.g. when the server loses its connection to the SAN - the other nodes did not take over in place of the failed node. This problem has now been fixed and failover from a failed HornetQ node now occurs without interruption to the client.
The default delay for message redelivery has been changed so that it's now 60000 milliseconds, or 1 minute. The default value was previously 0, which meant no redelivery delay. The specific change has been made in hornetq-configuration.xml.
An issue was discovered in a clustered HornetQ configuration where a client failed to connect (using JNDI) to the backup instance when the active node failed. The underlying cause of this issue was identified and fixed so that the client can now fail over from the active node to a backup node.
An issue was identified with cluster connections in that the core bridge service was ignoring the min-large-message-size specified in the configuration, instead using the default value of 100 KiB. This has been resolved and the min-large-message-size value is now recognized if specified in the configuration.
On server shutdown, HornetQXAResourceWrapper logs a warning on connection failure. This happens because the life-cycle of HornetQXAResourceWrapper is controlled by the Transaction Manager. The fix adds a recovery API to HornetQ, which fixes the issue.
HornetQ did not ship with a switch.bat script for customers running HornetQ on Microsoft Windows servers. While HornetQ could be installed by running ant in the HornetQ directory containing the build.xml file, this was not consistent with the Linux environment. A switch.bat script is shipped for Microsoft Windows customers, which replicates the script behavior in Linux environments.
It was discovered that the HornetQ core bridge service was hanging if the target server was terminated while large *bytemessages* of approximately 270MB were being delivered. The contents of the failed messages were not cleaned up from the target server's data/large-messages directory.
When the server was terminated more than once during large *bytemessage* transmission, multiple files would persist in thedata/large-messages directory. The only way to correct this issue was to restart the server that the bridge service was deployed on.
The fix implements changes to the core bridge, which now restarts until it successfully reconnects to the target server. The bridge no longer hangs when the target server is terminated, which corrects the issue.
In a clustered HornetQ configuration, messages 1 MB or larger in size could get stuck in the queue, resulting in a NullPointerException. This has been solved with large messages now catered for in a clustered configuration.
If the server crashed while transmitting a large message, the message remained in the large message directory unless removed manually. A temporary record is now added on the journal marking of the file and the file is deleted if corrupted.


IIOP deployments were not being deployed when using the standard profile because the file ejb3-iiop-deployers-jboss-beans.xml was not in $JBOSS_HOME/server/standard/deployers/ejb3.deployer/META-INF. This file is now present, and IIOP deployments now work in the standard profile.
A new CORBA naming context implementation has been added which uses a local cache to resolve names and avoid unnecessary remote calls.
Use of a custom CORBA servant inside an isolated EAR would cause ClassNotFoundExceptions if the servant tried to call an in-EAR EJB due to the use of an incorrect thread context classloader (TCCL) by JacORB. The cause of this problem has been fixed by ensuring that the TCCL of the servant class is used instead.


The installer had a Previous button available but if it was pressed, already installed files would be left installed. To prevent this occurring the Previous button is now disabled.
On Red Hat Enterprise Linux, menu items created by the installer were not available to all users, despite the checkbox "Create shortcuts for all users" being checked. The cause was inverted logic in the installer, so that the menu items created were available to all users only if the "Create shortcuts for all users" was not checked. This problem has now been fixed.
Menu items created by the installer on Microsoft Windows were not consistent with those created on Red Hat Enterprise Linux. The cause of the problem was that the run commands used in some of the menu items was invalid on Windows. The installer has been fixed so that all menu items are now valid on both operating systems.
Shortcuts created by the installer on Microsoft Windows had an incorrect path specified, which resulted in the shortcuts failing to start the platform. The path given included "jboss-as" but this should have been "jboss-as-web". The installer has now been corrected so that the shortcuts included the correct path.
On Windows, shortcuts which contained Asian characters were not removed by the uninstaller. The cause of the problem was found to be incorrect string encoding. This problem has since been fixed and all shortcuts created by the installer are successfully removed when the uninstaller is used.
The DVD Store demonstration Seam application provide with the Enterprise Application Platform failed to deploy. The application is now updated and will successfully deploy.
When running the installer with OpenJDK the buttons along the bottom of the window were cut off, making accessibility an issue. This has been resolved by changing their orientation slightly.
On Windows with either Japanese or Chinese localization settings, the Enterprise Application Platform's installer failed to create shortcuts in the Start menu and the users' desktop, requiring the user to manually start the application via either Windows Explorer or a Command Prompt. This problem has been fixed and the in these circumstances the installer now correctly creates shortcuts in both locations.


The JCA DTD (jboss-ds_5_1.dtd) referenced an element named "background-validation-minutes" but this was incorrect and should have been "background-validation-millis". This has now been corrected and the DTD now contains the element's correct name.
Datasources exposed remotely via RMI used the maps of connections and statements in a way that was not threadsafe. This resulted in either clients receiving an error message "unable to find statement" or the server getting stuck in an infinite loop due to the map data structure being corrupted. This issue has been resolved by changing the method of access to the remote datasource's map, so that it is thread-safe.
When recommended properties in an activation specification were not available, a DeploymentException error such as the following would occur:
08:20:50,262 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:binding=message-driven-bean,jndiName=local/gss_mdb_20@32140521,plugin=invoker,service=EJB state=Create mode=Manual requiredState=Installed
org.jboss.deployment.DeploymentException: Unable to create activation spec ra=jboss.jca:service=RARDeployment,name='wmq.jmsra.rar' 
The validation of properties has been changed and the following warning message is now output if an unknown or unsupported configuration property is detected:
17:52:45,801 WARN  [ActivationSpecFactory] Unable to set 'foo' property on org.jboss.resource.adapter.jms.inflow.JmsActivationSpec
A deadlock could occur when multiple threads accessed the JCA layer to either commit or roll back a transaction. The JCA code has been updated to resolve these problems and multi-threaded access should now work correctly.
The configuration settings allocation-retry and allocation-retry-wait-millis and no-tx-separate-pools did not work if they were specified in the configuration file (*-ds.xml) but did work if changed via the JMX Console. The cause of this problem has been resolved so these settings can now be configured via either method.


The Java security policies defined in bin/server.policy.cert were too strict, causing the JMX console to fail to load when the Java Security Manager was enabled. To resolve this issue, an entry was added to the bin/server.policy.cert file to relax the Security Manager restrictions.


The MessageSucker is responsible for migrating messages between different members of a cluster. The onMessage routine attempts to deliver messages to the local queue, among other tasks. If delivery failed, messages appeared to be lost. They were still in the database, but it was difficult to redeliver them. This was a defect in the JBoss Messaging component, and has been fixed in that component. The fix is complex, and is discussed in JBMESSAGING-1822, which is available at In short, a new layer of reliability has been added to the message delivery logic.
The messaging server would not start in default profile when configured to use a database other than HSQLDB database. This was caused by not commenting out lines in the database_type-persistence-service.xml file that were applicable only to clustered profiles.
The fix adds prescriptive comments to the database_type-persistence-service.xml file, instructing how to comment out unnecessary configuration directives for non-clustered messaging server instances.


A performance issue was identified in org.jnp.interfaces.NamingContext.checkRef, where every new InitialContext looped through the provider list in order. An unavailable node at the beginning of the provider list could cause a delay because it was waiting for a timeout before checking the next node. The fix adds an available JNDI Property (jnp.unorderedProviderList) and a system property ( These properties change the initial JNDI server lookup order when multiple providers are used. Without the property (default), each provider is still tried in order on every new InitialContext. With the new property set, any existing connection to any provider is used before checking the provider list in order again.


Deployment file names were not previously checked for legal paths. Poorly-constructed file names could cause unexpected file deletions or alterations. The deployment files are now checked for legal paths, and an exception is thrown if an illegal path is used.
If the Simple Logging Facade for Java or (SLF4J) was used in a top-level classloader such as the endorsed classpath, it would cause NullPointerExceptions. The cause of this problem has been resolved and SLF4J can now be used in a top-level classloader.
JAXB elements were not processed correctly when preceded by elements with xsi:nil=true. This issue has now been resolved and JAXB elements are processed correctly.
Configuration of "use_tccl=false|true" could be unreliable if there were several files. To fix this problem a new system property org.apache.commons.logging.use_tccl has been created, with the default still being true.
A deployment configured with parent-first=true is not delegating to the parent when loading resources (getResource). To enable this functionality set
and resources will be loaded parent-first if so configured. This can be done on the command or in the $JBOSS_HOME/bin/run.conf in JAVA_OPTS environment variable.
The "Migrating to HornetQ" section did not contain specific information about migrating JBoss Messaging applications where High Availability was concerned. A new section "Client-side Failure Handling" is now available in the guide, which details the extra code required to correctly handle HornetQ failover exceptions.
The XML Schema Declaration "jboss-xa-ds.xml" has been removed. All data source deployments in EAP 5.1.x should use the jboss-ds_5_1.dtd instead.
The getModulePath method of SimpleJavaEEModuleInformer did not follow the JavaEEModuleInformer specification as the getModulePath method returned an empty string for a top-level non-ear deployment. The method now returns the module name for such deployments and therefore meets the JavaEEModuleInformer specification.
In rare circumstances, a PagedReference could be garbage collected before messages were consumed, resulting in pagecredits getting out of sequence and the affected messages being stuck. A minimal page-size is one factor in the circumstances leading to this problem. This problem has now been solved by detecting and better handling these circumstances.
In an earlier release the caching behaviour in XMLReaderManager was removed to resolve a memory leak. This forced each invocation to recreate the XMLReader and, as a result of the presence of the Synchronized methods, contend with other threads. Caching has been reinstated through the use of the SAXParser class, resolving the issue of thread contention. The original issue of a memory leak is avoided by use of the SAXParser reset method.

Scripts and Commands

On RHEL 6 the JBoss service script had some backslashes incorrectly escaped, resulting in an invalid command and stopping JBoss being started or stopped. The script has been fixed and JBoss can reliably be started and stopped on RHEL 6.
On a "service stop" request on Red Hat Enterprise Linux the JBoss Enterprise Application Server service could fail to shutdown with a timeout failed error. The init script was modified to make sure the service shuts down correctly on service stop request.
When the log $JBOSS_HOME/server/$JBOSSCONF/log/server.log contained more than one instance of a server start-stop sequence, the shutdown script mistakenly detected that the server had shut down before it had actually been shut down properly. This problem has been fixed by changing the the script to monitor the server's process ID (PID) instead of the log file.
All *.xml and *.property files have been changed to Windows-compatible format (line endings). To change them to UNIX-compatible format, run the script jboss-eap-5.1/jboss-as/bin/, ensuring that you run it in the jboss-eap-5.1/jboss-as/bin/ directory.


An incompatibility with Microsoft Internet Explorer 8 and the Seam Tasks Example resulted in text appended to a task being represented as a blank line in the task list. The Seam Tasks Example was improved to display edited tasks correctly in Microsoft Internet Explorer 8.
An EAR project generated using seam-gen from EAP 5.1.1 contains some wrong dependencies in .classpath file: core.jar and janino.jar. These are no longer required and have been removed from Eclipse's classpath file and should be removed from any existing EAR project if you updated Seam and Drools jars from EAP 5.1.2 release in your existing EAR application.
When mail messages were created using the Seam Mail tag <ui:repeat...>, the list of attachments was cached and so each recipient received the attachment multiple times. This has been fixed by resetting the attachments list after it has been added to the message's body.
The ServerConversationContext.flush() method created in some cases PersistentContext and BusinessContext instances and these instances lived in memory until the HTTP Session was invalidated. This problem is solved by creating them only when required.
A multipart request was not parsed correctly if CRLF+CRLF (Carriage Return Line Feed) in the header line was separated at the buffer boundary; that is, the header buffer ended with CRLF and the following byte was CRLF. This caused a MultipartRequest error and excessive CPU memory usage. Such multipart request is now parsed correctly and the error no longer occurs.
The org.apache.el.util.concurrentcache class did not synchronize requests for concurrent access to WeakHashMap. In some cases, this caused an infinite loop, which consumed excessive CPU memory. The underlying issue has now been resolved and access to WeakHashMap in the org.jboss.el.util.concurrentcache class is now synchronized.
It was found that the Attribute Exchange (AX) extension of OpenID4Java was not checking to ensure attributes were signed. If AX was being used to receive information that an application only trusts the identity provider to assert, a remote attacker could use this flaw to conduct man-in-the-middle attacks and compromise the integrity of the information via a specially-crafted request. By default, only the JBoss Seam openid example application uses OpenID4Java. (CVE-2011-4314).
  • openid4jav-nodeps.jar
  • httpclient.jar
  • httpcore.jar
  • nekohtml.jar
  • jcip-annotations.jar
  • guice.jar
  • commons-codec.jar


It was found that the invoker servlets, deployed by default via httpha-invoker, only performed access control on the HTTP GET and POST methods, allowing remote attackers to make unauthenticated requests by using different HTTP methods. Due to the second layer of authentication provided by a security interceptor, this issue is not exploitable on default installations unless an administrator has misconfigured the security interceptor or disabled it. (CVE-2011-4085)
In prior EAP 5 releases, use of cglib.jar would cause security exceptions since code generated by cglib overlapped with the cglib JAR packages that were signed. To resolve this issue cgilib.jar has been unsigned and the security policy has been modified to account for this change.
Under heavy load a ConcurrentModificationException could occur in the SimpleRoleGroup class, resulting in the user being unauthorized. The cause of this problem has been identified and corrected and no longer occurs.


When a Long value was passed in to the SNMP Adapter, there was no option to convert this to a Counter64 type but only as Gauge32. This caused the return value to be of the incorrect type 32bit and not 64bit. The JVM argument -Djboss.snmp.use64bit is now available. It can be used to specify that 64bit data types should be returned by the SNMP adapter. Usage -Djboss.snmp.use64bit=true. The default value is false. When set, all Long types are returned as 64bit values. For backward compatibility the default value is false so existing setups will not change when a later version of the code is used.


The security interceptor did not create a security context if one did not already exist. A new clean thread (the thread with no security context) was unable to invoke the local interface of the EJB. However, a new clean thread was able to invoke the remote interface of an EJB without any problems. The fix provides modifications to the PreSecurityInterceptor, which now creates a new security context if one does not exist. A new thread with no security context is able to invoke the local interface of the EJB.


When Jasper was using the ParserUtils of JAXP, the calls between the framework's classes and deployment's classes were blocked because they were deliberately isolated from each other. To avoid this problem these calls have been modified so that they work in an isolated environment.
Because of an issue in Tomcat, the time offset when Daylight Savings Time came into effect was wrong. This has since been fixed and the offset calculations are now correct.
If there was a @PostConstruct annotation, or other annotation, on a method which was overloaded by another method with the same name, the call to that method would fail with an exception error. This occurred because no arguments were passed to the method and only the presence or absence of the method was being checked, not the presence or absence of methods. To resolve this issue further checks have been added so that the presence of parameters is confirmed prior to the method being invoked.
When mixed methods of authentication were used in the one deployment, the WebAuthentication method would prevent the start of a single sign-on (SSO) session. This problem is resolved and WebAuthentication now works correctly with SSO sessions.
An error occurred when a getter method returned an empty string and numeric conversion was attempted. This has been fixed by testing for and better handling the empty string.
The injection of @EJB or @Resource fields into superclasses of JSF Managed Bean were failing. When @EJB were to be injected via annotations, those annotations were not being processed, leaving their fields null, or otherwise unset. The cause of this issue has been resolved and these injections now work as expected.

Web Services

The CXF installer removed the jettison.jar, stax-ex.jar, and streambuffer.jar files from the client/ directory if they were available. However, these files could be used by non-WS clients and some applications could fail to work after CFX upgrade or installation. The installer now no longer removes these files and the applications work as expected even after CXF installation or upgrade.
An endpoint implementation annotated with @HandlerChain and WS-Security (WSSE) enabled caused a duplicate SOAP body to be appended. The cause of this problem has been resolved and no duplication now occurs.
In JBoss EAP 5.1.1, running the httpbinding example caused errors. These occurred because JBossWS Native forced JBoss Remoting to close the streams. This enforcing introduced regressions that have been fixed in JBoss EAP 5.1.2.
Some clients failed to parse web service responses sent from JBoss that were MTOM/XOP encoded because JBoss Web Services failed to add the "charset" parameter to the root MIME part if the used charset was different from the implicit default "ISO-8859-1". The "charset" parameter is now added to the web service response if necessary.
The system threw a RuntimeException if a policy reference was wrapped in a <wsp:policy> element in a wsdl file. This happened because it failed to resolve the policy reference. The policy reference can now be either wrapped in the <wsp:Policy> element or defined as a standalone element (without being wrapped in the <wsp:Policy> element).
JBossWS shell script and batch files from the CXF stack (wsconsume, wsprovide, wsrunclient) were inconsistent with their use of the configuration option. This has been changed and both the Native and CXF stacks are configured with an IPv4 preference.
The schema validation feature supported one imported schema only. Now, you can define @SchemaValidation on a WSDL that defines multiple schema imports.
SOAPFactoryImpl forces additional namespace declarations in all child elements that are not immediate child elements of the element declaring the namespaces. This explicit declaration is redundant and is now no longer added.
JBoss Web Services threw an org.w3c.dom.DOMException when it attempted to create a dispatch client with an EnpointReference. This happened because the server appended a node from another document to the dispatch client in some concurrent environments. JBoss Web Services now appends the correct node to the dispatch client and creates the dispatch client with an EndpointReference correctly.
The password digest of the UsernameToken profile used in JBoss Web Services did not follow the Oasis specification as the digest used the base64 encoded nonce. As a result, the process was incompatible with other web service implementations that support UsernameToken profile. The password digest has been corrected to use the binary value of the nonce and JBoss Web Services works with other implementations in the UsernameToken profile as expected.
JBossWS native does not properly protect against recursive entity resolution with embedded DTDs. A remote attacker could cause a Denial-Of-Service by CPU resource exhaustion with a carefully crafted POST request to a deployed web service. (CVE-2011-1483)
The JBossWS-CXF JAXWS client relies on the CXF ProviderImpl which requires a Bus instance. Unless a Bus was associated with the current thread, the Bus retrieval process returned the Bus instance that was created for the server. Now a customized Provider implementation creates a new Bus instance for the client and the Bus request returns this Bus instance.
When a CXF endpoint received an HTTP GET request, it threw a NullPointerException at org.apache.cxf.staxutils.StaxUtils.readDocElements. Although a GET request to the endpoint should cause an exception, a NullPointerException is not appropriate. The endpoint now filters the GET requests and safely skips the code that caused the exception.
If a wsdl part contained a header with partIndex 0, the JAX-WS runtime threw an IllegalArgumentException due to an incorrect number of arguments in the dispatch/provider service. With this update the arguments are checked and added to the argument list as expected.
When a client sent a message with an MTOM (Message Transmission Optimization Mechanism) attachment, which was larger than 64K to JBoss Web Services, the server deleted the swap file in ServiceEndpointInvoker before the response message processing was completed and returned a FileNotFoundException. Now the swap file is deleted after the response processing has been completed and the error no longer occurs.

Chapter 5. Known Issues

Known issues in Enterprise Application Platform 5.1.2 are listed by component.


When the same EJB is deployed to two different clusters, the InvokerInterceptor calls the local EJB instead of the EJB on cluster 2, even though the InitialContext is pointed to the JNDI of a server in cluster 2. This problem is not yet resolved but to work around the issue, set the following configuration item either via the JAVA_OPTS environment variable or in $JBOSS_HOME/bin/run.conf:


If you change the database properties via the Admin Console, the changes are persistent. However, if you undo the changes, the old values still persist when you restart the Application Server. This problem is not yet resolved, but you can work around it by editing the associated attachments file in server/PROFILE/data/attachments, to force the datasource configuration to use the new settings.


It is not possible to upgrade an Enterprise Application Platform from JBoss Messaging to HornetQ, using the binary installer. You can download the HornetQ binaries separately, and follow the instructions in the HornetQ User Guide to move from JBoss Messaging to HornetQ.


A customer attempted to deploy an EJB 2.0 MDB which was configured to use message inflow by overriding the configuration-name with "Standard Message Inflow Driven Bean". The server attempted to set up a JCA inflow without knowing the messaging type, which resulted in a "java.lang.ClassNotFoundException: Null class name" error. This is an illegal configuration as per EJB 2.0 FR2 15.4.2 and EJB 2.1 FR 15.4.2. To work around this issue, you can force the server to treat every MDB as a JMS MDB by using invoker-proxy-binding-name 'message-driven-bean' in standard-jboss.xml. Alternatively, you can configure MDBs individually in the jboss.xml file. MDBs configured as such will be treated as EJB 2.1 JMS MDBs and subsequently get a messaging-type of MessageListener. This might conflict with other overrides to messaging-type.


When batch insert statements are ordered, embedded classes are not taken into account. There are two possible workarounds for this issue. The first is to set ORDER_INSERTS to FALSE when embedded classes are used. The second option is to explicitly call on child objects to enforce their SQL insertion orders.
You are not allowed to initialize lazy collections or proxies during a flush. The workaround is for the listener to use a different session to initialize the collection. The following is an example of the workaround:
SessionImplementor si = (SessionImplementor)(event.getSession());
Session anotherSession = si.getFactory().openSession(si.getJDBCContext().connection());
Object obj = anotherSession.get( event.getEntity().getClass(),event.getId());
if(o instanceof Parent){
 Parent parent = (Parent)obj;
 Iterator it = parent.getChildren().iterator();
  Child child = (Child);
When using the Criteria API with LEFT OUTER JOIN to add criterias to children, the child collections will only contain those children matching the criteria. This behavior also applies when not using any Filters. For example: criteria.createCriteria("children", JoinFragment.LEFT_OUTER_JOIN). There is no workaround for this issue.
An "InitialContext did not implement EventContext" WARN message originating from SessionFactoryObjectFactory was causing concern when viewing debug information. Hibernate can bind the SessionFactory to JNDI after startup if it can find the session factory name from the server configuration, however the result in the WARN message, which is misleading in its severity. Users can not prevent this message from displaying, and the message itself is usually caused by an environment-specific issue. To avoid seeing the WARN message, adjust the logging level to "debug".


The following examples provided with HornetQ don't work for various reasons:
  • jca-remote
  • jms-bridge
  • mdb-remote-failover-static
  • mdb-remote-failover
  • xarecovery
  • embedded-simple
  • embedded
  • failover-manual-stop
  • jaas
  • spring-integration
  • stomp-websockets
  • stop-server-failover
  • transaction-failover
HornetQ's installer copies its own version of netty.jar to the directory jboss-as/common/lib, resulting in a duplicate file of different versions because the same file is already installed by the EAP installer in the directory jboss-as/client. The workaround is to delete netty.jar from the directory jboss-as/common/lib.
An issue with HornetQ cluster nodes in a dedicated/colocated topology has been identified where a Null Parameter Exception can occur if the nodes are started at the same time. The cause appears to be a timing issue with topology messages passed between the nodes. The workaround is to start the nodes sequentially.
An issue has been identified in which a RejectExecutionException may occur if the platform is shut down while the server is still processing requests. Messages similar to the following are recorded in the log. The workaround to this issue is to first confirm that there is no activity before shutting down the server.
[JBoss] java.util.concurrent.RejectedExecutionException
[JBoss] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(
[JBoss] at java.util.concurrent.ThreadPoolExecutor.reject(
[JBoss] at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(
[JBoss] at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(
[JBoss] at org.hornetq.core.server.impl.QueueImpl.<init>(
[JBoss] at org.hornetq.core.server.impl.QueueFactoryImpl.createQueue(
[JBoss] at org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(
[JBoss] at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(
[JBoss] at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(
[JBoss] at org.hornetq.core.server.impl.HornetQServerImpl$
[JBoss] at
An issue has been identified where an NullPointerException can occur in the platform on Red Hat Enterprise Linux with OpenJDK if reconnection retries are occurring while the platform is being shut down. Messages similar to the following are reported in the log. The workaround to this issue is to confirm that there is no activity before shutting down the server.
[Thread-8 (HornetQ-server-HornetQServerImpl::server 2-10536304)] 16-Dec 7:46:11,567 WARNING [ServerLocatorImpl] NULL
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl.onConnection(
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.getConnection(
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connect(
at org.hornetq.core.client.impl.ServerLocatorImpl$StaticConnector$Connector.tryConnect(
at org.hornetq.core.client.impl.ServerLocatorImpl$StaticConnector.connect(
at org.hornetq.core.client.impl.ServerLocatorImpl.connect(
at org.hornetq.core.client.impl.ServerLocatorImpl$
If HornetQ fails during delivery of a message between bridges, the target queue can have its management counters affected by a small number of elements. This issue does not affect the actual operation of HornetQ itself, only statistics reporting.
If a HornetQ backup server is shutdown prior to the live server being shut down, an IllegalStateException may occur, with messages similar to the following reported in the log:
11:18:56,234 INFO  [ServerImpl] Runtime shutdown hook called, forceHalt: true
11:18:56,237 WARN  [StartStopLifecycleAction] Error during stop for org.hornetq:module=JMS,type=Queue,name="ExpiryQueue"
java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
	at org.hornetq.jms.server.impl.JMSServerManagerImpl.checkInitialised(
	at org.hornetq.jms.server.impl.JMSServerManagerImpl.removeQueueFromJNDI(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
There is no workaround for this issue.
An issue has been identified where an NullPointerException can occur in ServerLocatorImpl if the platform is shut down while activity is still occurring. Messages similar to the following are reported in the log. The workaround to this issue is to confirm that there is no activity before shutting down the server.
[junit] * [Thread-6 (HornetQ-server-HornetQServerImpl::serverUUID=147484f9-3aa9-11e1-aff0-1fd4a2111687-22518320)] 9-Jan 5:2:46,510 WARNING [ServerLocatorImpl] NULL
[junit] java.lang.NullPointerException
[junit] at org.hornetq.core.client.impl.ServerLocatorImpl$StaticConnector.connect(
[junit] at org.hornetq.core.client.impl.ServerLocatorImpl.connect(
[junit] at org.hornetq.core.client.impl.ServerLocatorImpl$
[junit] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$
[junit] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
[junit] at java.util.concurrent.ThreadPoolExecutor$
An issue has been identified where an NullPointerException can occur in ClientSessionFactoryImpl if the platform is shut down while activity is still occurring. Messages similar to the following are reported in the log. The workaround to this issue is to confirm that there is no activity before shutting down the server.
[junit] java.lang.NullPointerException
    [junit] 	at org.hornetq.core.client.impl.ClientSessionFactoryImpl$PingRunnable.send(
    [junit] 	at org.hornetq.core.client.impl.ClientSessionFactoryImpl.getConnection(
    [junit] 	at org.hornetq.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(
    [junit] 	at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connect(
    [junit] 	at org.hornetq.core.client.impl.ServerLocatorImpl$StaticConnector$Connector.tryConnect(
    [junit] 	at org.hornetq.core.client.impl.ServerLocatorImpl$StaticConnector.connect(
    [junit] 	at org.hornetq.core.client.impl.ServerLocatorImpl.connect(
    [junit] 	at org.hornetq.core.client.impl.ServerLocatorImpl$
    [junit] 	at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$
    [junit] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    [junit] 	at java.util.concurrent.ThreadPoolExecutor$
    [junit] 	at


Two JBoss Messaging Test Suite tests fail on Oracle 11g R1, R2 and RAC with the latest JDBC driver, version
  • QueueManagementTest.testDestroyDestinationProgrammatically
  • QueueManagementTest.testDestroyDestinationProgrammaticallyWithParams
These tests use a large value for the fullSize queue configuration parameter, which is passed to the setFetchSize method on the java.sql.PreparedStatement. A problem with the JDBC driver means that more than the usual amount of memory is consumed when executeQuery() is called, which results in a java.lang.OutOfMemoryError, causing the test to fail.


The TwitterClient example is deprecated in RESTEasy 1.2.x due to Twitter deprecating the Basic Authentication method in August 2010. All applications must now use OAuth. RESTEasy 2.x contains a reworked TwitterClient example that includes OAuth. Download the example from the newest version of RESTEasy for testing purposes.


Seam projects created using JBDS earlier than version 4.1.1 failed the test phase with the message:
Could not instantiate Seam component:
Caused by: java.lang.RuntimeException: The Eclipse JDT Core jar is not in the classpath
This error occurred because, since an upgrade of Drools to 5.1, functions required by JBDS which would previously been found in lib/core.jar are now contained in lib/ecj.jar. To workaround this problem, take one of the following options, with option 1 being the recommended option:
  1. Upgrade JBDS to 4.1.1;
  2. Copying lib/ecj.jar to the project.


When java.sql.Date.valueOf attempts to parse dates of the format yyyy-mm-dd, the TCK test threw a java.lang.IllegalArgumentException. This was due to a regression in the latest Sun JVM, Sun JDK 1.6.0_24 (see for more information). The workaround for this issue is to downgrade to Sun JDK 1.6.0_17.

Transaction Manager

An issue has been identified with JBoss Web Services which results in an error similar to the following when attempting the deployment of XTS Transactions. A workaround is to add to the JBoss Enterprise Application Platform run parameters. Refer to the Getting Started Guide for details of how to add to run parameters.
14:00:57,054 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/tmp/EAP5.1.2/jboss-eap-5.1/jboss-as/server/all/deploy/jbossxts.sar/ state=PreReal mode=Manual requiredState=Real 
        org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/tmp/EAP5.1.2/jboss-eap-5.1/jboss-as/server/all/deploy/jbossxts.sar/ws-c11.war/ 
                at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException( 
        Caused by: Cannot publish wsdl to: /tmp/EAP5.1.2/jboss-eap-5.1/jboss-as/server/all/data/wsdl/jbossxts.sar/ws-c11.war/wscoor-activation-binding.wsdl 
                at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles( 
        Caused by: org.xml.sax.SAXParseException: DOCTYPE is disallowed when the feature "" set to true. 
                at org.jboss.wsf.common.DOMUtils.parse( 
                at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports( 
          Deployment "vfsfile:/tmp/EAP5.1.2/jboss-eap-5.1/jboss-as/server/all/deploy/jbossxts.sar/" is in error due to the following reason(s): org.xml.sax.SAXParseException: DOCTYPE is disallowed when the feature "" set to true.


An IllegalStateException is thrown when a datasource with a web application dependency is restarted.

Appendix A. Revision History

Revision History
Revision 5.1.2-109.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revision 5.1.2-1092012-07-18Anthony Towns
Rebuild for Publican 3.0
Revision 5.1.2-108Wed 9 February 2012Russell Dickenson
Fixed quoted HornetQ version, as per Bugzilla:
Revision 5.1.2-107Thu 19 January 2012Russell Dickenson
Incorporated changes for JBoss Enterprise Application Platform 5.1.2 GA. For information about documentation changes to this guide, refer to Release Notes 5.1.2.

Legal Notice

Copyright © 2011 Red Hat.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.