JBoss Enterprise Application Platform 4.3

Release Notes CP05

for Use with JBoss Enterprise Application Platform 4.3 Cumulative Patch 5

Isaac Rooskov

Legal Notice

Copyright © 2009 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.


1801 Varsity Drive
RaleighNC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
PO Box 13588 Research Triangle ParkNC 27709 USA

Abstract
These release notes contain important information related to JBoss Enterprise Application Platform 4.3.0.CP05 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 4.3.0.CP05.

1. Introduction
1.1. Overview
2. New Features in JBoss Enterprise Application Platform 4.3
2.1. JBoss Messaging
2.2. JBoss Web Services 2.0.1
3. Component Versions
4. Installation and Migration Notes
4.1. Installation Notes
4.2. Upgrading from JBoss Enterprise Application Platform 4.3.0.CP04
5. Important Notes
5.1. Running the example Seam Applications
5.2. Default Security Settings
5.3. Embedded Hypersonic Database
5.4. Source Files
6. Product Support and License Website Links
7. Documentation
8. Issues fixed in this release
9. Known Issues with this release
A. Revision History

1.  Introduction

These release notes contain important information related to JBoss Enterprise Application Platform 4.3.0.CP05. New features, known problems, resources, and other current issues are addressed here.

1.1. Overview

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.
JBoss Enterprise Application Platform provides complete compatibility with existing J2EE 1.4 enterprise Java applications. At the same time, almost all the key features and components defined in the Java EE 5.0 specification are supported. So your new enterprise Java applications can take immediate advantage of the Java EE 5.0's significantly simpler POJO-based programming model.
Further, by integrating best-of-breed open source frameworks such as JBoss Seam, Hibernate, Tomcat, and JBoss Cache 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.
All of which means you can develop your new application taking advantage of Java EE 5.0 technologies immediately and with the confidence of knowing it will remain forward-compatible with future versions of the JBoss Platform.

2. New Features in JBoss Enterprise Application Platform 4.3

2.1. JBoss Messaging

In JBoss Enterprise Application Platform 4.3, JBoss MQ 1.3 has been replaced with JBoss Messaging 1.4. JBoss Messaging provides a high performance messaging infrastructure for JBoss Enterprise Application Platform.
A known issue exists within the JBoss Messaging component that allows for duplicate message IDs to be generated and may cause production software issues. Enterprise Application Platform 4.3.0.CP06 will be released shortly and will contain the necessary bug fix.

Important

For more information about this issue that may impact your production server see Section 9, “ Known Issues with this release ”.

2.2. JBoss Web Services 2.0.1

JBoss Web Services is upgraded to 2.0.1 in JBoss Enterprise Application Platform 4.3 and will now provide a complete implementation of JAX-WS.

3. Component Versions

This section details the versions of the components which create the Enterprise Application Platform 4.3 that can be found in this Cumulative Patch release.
  • JBoss Application Server 4.2.z
  • Hibernate Core 3.2.4.SP1.CP08
  • Hibernate Annotations 3.3.1.GA_CP01
  • Hibernate Entity Manager 3.3.2.GA
  • Hibernate Validator 3.0.0.GA
  • JAF 1.2_10
  • JBoss Cache 1.4.1_SP13
  • JBoss JAXR 1.2.0.SP2
  • JBoss Messaging 1.4.0.SP3-CP08
  • JBoss Remoting 2.2.3
  • JBoss Transactions 4.2.3.SP5.CP05
  • JBoss Web 2.0.0.CP10
  • JBoss Web Services 2.0.1.SP2_CP06
  • JGroups 2.4.6
  • JSF 1.2_10
  • Seam 1.2.1.AP
  • Xalan 2.7.0.patch02

Note

The Enterprise Application Platform Server has been redefined for the enterprise market to a level where direct association to a community release can no longer be drawn.

4. Installation and Migration Notes

This section contains information related to installing or upgrading to JBoss Enterprise Application Platform version 4.3.0.CP05, including hardware and platform requirements and prerequisites.

4.1. Installation Notes

You must have adequate disk space to install JDK and JBoss Enterprise Application Platform while also allowing enough space for your applications. You must have a working installation of JDK 1.5 or 1.6. For the latest information on supported Operating System / JVM combinations, supported Database platforms and current information on the revision level of included components, please refer to http://www.jboss.com/products/platforms/application/testedconfigurations. Refer to the installation guide available online from http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/ for detailed instructions to install and verify JBoss Enterprise Application Platform.

4.2. Upgrading from JBoss Enterprise Application Platform 4.3.0.CP04

Using CSP/JON
Refer to https://network.jboss.com/confluence/display/DOC/Installing+a+Patch for instructions on installing a Cumulative Patch.

5. Important Notes

A known issue exists within the JBoss Messaging component that allows for duplicate message IDs to be generated and may cause production software issues. Enterprise Application Platform 4.3.0.CP06 will be released shortly and will contain the necessary bug fix.

Important

For more information about this issue that may impact your production server see Section 9, “ Known Issues with this release ”.

5.1.  Running the example Seam Applications

It is recommended to run the example Seam applications that are included with the documentation using the production configuration. Using another configuration may result in memory issues. Note that the default configuration for the server to start with, if no other configuration is specified, is the production configuration.

Warning

To avoid memory issues, adjust the memory settings before deploying the applications. You can do this by updating JAVA_OPTS settings in the file JBOSS_DIST/jboss-as/server/production/run.conf with these recommended values:
-Xms1303m -Xmx1303m -XX:PermSize=256m -XX:MaxPermSize=256m
Refer to the "Seam Reference Guide" included in the documentation set (JBOSS_DIST/doc/seam/Seam_Reference_Guide.pdf) for important information regarding the deployment of Seam examples and detailed information on developing applications using Seam.

5.2.  Default Security Settings

If you are using the rpm, or the zip distribution, please note that by default, authentication is enabled and no user accounts are set up. This is done to prevent unauthorized access to various services of JBoss AS. Please refer to the Installation Guide, or see http://kbase.redhat.com/faq/FAQ_107_9963.shtm for information on how to make the services accessible again.

5.3.  Embedded Hypersonic Database

Hypersonic SQL provides default "out of the box" database functionality for evaluation and development use only. It is NOT recommended or supported as a production-use database. Technical support is not available for this component, and while we are happy to accept bugs filed against this component, we do not make any commitment to fix them within a specific timeframe.
Production Support Scope of Coverage
http://www.redhat.com/support/policy/soc/production
Production Support Service Level Agreement
http://www.redhat.com/support/policy/sla/production/
Developer Support Scope of Coverage
http://www.redhat.com/support/policy/soc/developer/
Developer Support Service Level Agreement
http://www.redhat.com/support/policy/sla/developer/
Product Update and Support Policy by Product
http://www.redhat.com/security/updates/jboss_notes/
JBoss End User License Agreement
http://www.redhat.com/licenses/jboss_eula.html

7.  Documentation

Refer to the index.html file in the documentation directory for a list of included documentation.
In the zip distribution, documentation for the Platform and its individual components is distributed in a separate zip file, jboss-eap-docs-<version>.zip.
On a Linux system, the documentation is found in two rpms that will need to be installed manually. These rpms are jboss-seam-docs-<version>.noarch.rpm, and rh-eap-docs-<version>.noarch.rpm. For help with installing rpm packages on Red Hat Enterprise Linux, please refer to the Red Hat Knowledge base article located at http://kbase.redhat.com/faq/FAQ_35_198.shtm
  • Installation Guide explains how to install and verify the installation of JBoss Enterprise Application Platform using different installation modes.
  • Getting Started details the directory structure of the platform and a quick tour of the Application Server and different configuration sets and services. Using a simple web application it illustrates the use of JSF-EJB3 components and how to use Seam to integrate the JSF and EJB3 components.
  • Server Configuration Guide explains all administrative and configuration functions in detail.
Updated versions of the documentation with errata and additional information, example application code, as well as the most recent version of the release notes may be accessed via the web from http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/.

8.  Issues fixed in this release

Following is a list of issues fixed in this release:
JBoss Messaging
  • JBPAPP-2029: The JBoss Messaging component of the Enterprise Application Platform has been upgraded to version 1.4.0.SP3-CP08. A list of the included fixes is as follows:
    • JBMESSAGING-1620: JBoss Messaging did not display any notifications when the client connections were closed and this feature was now being requested. In order to include this feature, the SimpleConnectionManager.java file has been updated to synchronize the AspectManager instances and create a new connection advisory before the connection close in order to capture the notifications when the close occurs.
    • JBMESSAGING-1614: The limit for bridges was formally 256 as each bridge participant required a unique ServerPeerID that was an 8-bit value. However users have wished to bridge more than 256 servers to a single host and to allow for this the limit has been increased to 65535 (16-bit).
    • JBMESSAGING-1608: A bug arose when the server instance of JBoss Messaging performed a restart as the MessagingXAResourceRecovery instance on the client machine would not reconnect correctly to the new server instance and instead display a warning to the user concerning a generated exception in the program. This issue has been corrected by modifying the MessagingXAResourceWrapper.java file to verify the connection, catch any generated JMSException and test if the connection is still valid following an exception.
    • JBMESSAGING-1607: When the bisocket-remoting-service.xml was updated in previous releases, the sslbisocket-remoting-service.xml missed being updated accordingly. The following parameters were missing and have now been added in order to ensure remoting configuration functions correctly:
      <attribute name="validatorPingPeriod" isParam="true">10000</attribute>
      <attribute name="validatorPingTimeout" isParam="true">5000</attribute>
      <attribute name="registerCallbackListener">false</attribute>
      
    • JBMESSAGING-1591: When a system crash would occur, the server would not properly close references to instances of the ServerInvokerCallbackHandler, resulting in a memory leak. This bug has been corrected by modifying the ServerConnectionEndpoint.java file so that the callbackHandler.shutdown(); method is called in the try code instead of calling callbackHandler.getCallbackClient().disconnect();.
    • JBMESSAGING-1562: Channel name resolution was not correct in the MessagingPostOfficeService.startService() method. Where the code was:
      String channelName = (channelPartitionName == null)? channelPartitionName : groupName;
      
      The code now is:
      String channelName = (channelPartitionName != null)? channelPartitionName : groupName;
      
      Where the difference is that the channelPartitionName is tested to not be null instead of being null. This alteration ensures that the channel name is resolved correctly.
    • JBMESSAGING-1547: A potential deadlock case may have eventuated in earlier releases of JBoss Messaging when a message Sucker was being stopped due to the remote queue leaving, while the corresponding localQueue was delivering messages and trying to pass messages to its Suckers. In order to ensure this deadlock can no longer occur, the MessageSucker.java file has been updated to move the localQueue.unregisterSucker(this) method call to the beginning of the stop() method in order to prevent the message Sucker from being accessed while it is shutting itself down.
    • JBMESSAGING-1543: If a Message Bridge failed on the first attempt at connecting to a server because of any reason and then the server was found, the bridge connection would still fail (unless explicitly instructed to reconnect) even though a success message is displayed to the user. The issue is fixed by editing Bridge.java to ensure that the StartupFailureHandler starts the checker thread even if the bridge connection fails so that it is ready to start on a successful reconnection.
    • JBMESSAGING-1516: Functionality has been added to the MessagingPostOffice where users can now perform changes to the failoverOnNodeLeave property in order to give administrators improved flexibility with what should occur when a JBoss Messaging cluster node is shutdown under normal circumstances.
    • JBMESSAGING-1456: Messages would not move from the being-delivered state when clients used a clustered XA connection factory in a cluster of at least two nodes without a restart of the servers. This was caused because when the client connection failed, the server side would not always be notified, which meant that messages would not be canceled and redelivered. To correct this behavior a new feature was added to the JBoss Remoting component to enable the necessary strict binding between a client and the server connection failure management. Correct synchronization is achieved through this, also fixing an issue of inaccurate message counts. The following new parameters have been introduced to the Remoting configuration file:
      <attribute name="failureDisconnectTimeout" isParam="true">0</attribute>
      <attribute name="callbackErrorsAllowed">1</attribute>
      <attribute name="useClientConnectionIdentity" isParam="true">true</attribute>
      
      This fix means that a customer can be assured that JBoss Messaging reliably delivers messages without missing data or discontinuity of the mission critical application.
    • JBMESSAGING-1416: The functionality of strict messaging has been added to the JBoss Messaging component. This allows for a user to determine an ordering group and only one message with the value of an ordering group is delivered at once. After the message is acknowledged or cancelled the next message is delivered.
    • JBMESSAGING-1131: JBoss Messaging used to only use socket transport for delivering messages. In this latest release, JBoss Messaging now supports servlet transport through cooperation with the JBoss Remoting component, improving the functionality of JBoss Messaging.
JBoss Cache
  • JBPAPP-1993: The JBoss Cache component of the Enterprise Application Platform has been upgraded to version 1.4.1_SP13. A list of the included fixes is as follows:
    • JBPAPP-1995: The RegionManager.createRegion method would allow duplicate region names and when this occurs all future cache operations would happen only on the second instance of the region, while the EvictionTimerTask will only watch the first instance, causing the eviction queue of the second instance to fill. To correct this bug, the RegionManager.checkConflict method now counts a duplicate as a conflict and causes the RegionManager.createRegion method to generate an exception.
    • JBPAPP-1994: The findNode method of TreeCache generated a NullPointerException when the findInternal method returned a null value. The findNode method can now handle a null value returned from the findInternal method by checking within the TreeCache.java file if the toReturn value is null as well as the version
JBoss Remoting
  • JBPAPP-1996: The JBoss Remoting component of the Enterprise Application Platform has been upgraded to version 2.2.3. A list of the included fixes is as follows:
    • JBREM-1129: It was possible for PING messages to arrive out of order because socket and bisocket transports use a pool of connections. To fix this bug when a org.jboss.remoting.Lease is created a timestamp is associated with it and carried by an initial PING message. The contents of an updated PING message will now be discarded if its timestamp is older than the previously processed timestamp. In the occurrence that the initiating PING message does not have a time stamp, the lease will assume that the client is using an older version of JBoss Remoting and it will accept all updated PING messages.
    • JBREM-1128: Connection identity for the LeasePinger and Lease pair has been added by setting the parameter org.jboss.remoting.Remoting.USE_CLIENT_CONNECTION_IDENTITY to true. JBoss Remoting then identifies a connection with a LeasePinger and Lease pair and a client participates in a connection when it is connected by way of the new method connect(ConnectionListener listener, Map metadata). This method serves to connect the client to the server by way of a new or existing client invoker, and it also registers the ConnectionListener with the client's new or exiting ConnectionValidator, while also registering the ConnectionValidator with the client invoker's LeasePinger. Subsequently, if any ConnectionValidator registered with that LeasePinger detects a connection failure, it will (if the stopLeaseOnFailure parameter is set to true) stop the LeasePinger, and the LeasePinger will cause each registered ConnectionValidator to notify each of its registered ConnectionListeners of the connection failure. If a client is reconnected by a call to the Client.connect() method, it will be associated with a new LeasePinger and be treated as a new connection.
    • JBREM-1127: ClassCastExceptions would arise from the caching of Unmarsharller and Classloader in the MicroRemoteClientInvoker and performing classloading when accessing a remote bean from separate isolated EARs. In fixing this issue the MicroRemoteClientInvoker.java file has been updated to modify the use of useCurrentThreadClassLoader, the variable useCurrentThreadClassLoader has been added to RemotingClassLoader.java, and JavaSerializationManager.java has been modified to update the ObjectInputStream classloader if the useCurrentThreadClassLoader variable of RemotingClassLoader has a value of true.
    • JBREM-1125: When a java.util.Timer class no longer had TimerTasks in its queue, it would allow itself to shut down. This behavior caused subsequent calls to the Timer.schedule() method to generate a java.lang.IllegalStateException. The exception has been overcome by modifying the AbstractDetector.java file to test for an IllegalStateException when scheduling on the heartbeatTimer and Timer.
    • JBREM-1121: Functionality has been added to the client SocketFactory that allows it to be configurable by the InvokerLocator so that all the parameters from the InvokerLocator are available instead of only those in the configuration map.
    • JBREM-1119: If the application called the org.jboss.remoting.Client.removeListener() method, then ServerInvoker would remove references to ServerInvokerCallbackHandler, and it would call the ServerInvocationHandler.removeListener() method, granting the application a chance to remove the reference it held. An issue arose if the connection from the client was to break as that would cause none of the above to be executed, leading to a memory leak in the program. To fix the problem, ConnectionNotifier now uses copies of lists in order to avoid a ConcurrentModificationException, a shutdown() method has been added to the ServerInvokerCallbackHandler, and within the ServerInvoker the removeCallbackHandler() method has been made public and a shutdownCallbackHandler() method has been added. These changes mean that the shutdown() method within the ServerInvokerCallbackHandler can be used by the application to remove the necessary references by utilizing the ServerInvoker and the applications ServerInvocationHandler.
    • JBREM-1112: Upon a connection failure there was occurrences of a race condition occurring between the ConnectionValidator and ConnectionListener as ConnectionValidator may be able to execute the Client.getDisconnectTImeout() method before a ConnectionListener executes Client.setDisconnectTimeout(), causing the program to behave unexpectedly. This issue has been fixed by introducing a new parameter called ConnectionValidator.FAILURE_DISCONNECT_TIMEOUT (with the actual value of failureDisconnectTimeout). If the org.jboss.remoting.Client.USE_ALL_PARAMS property (with the actual value of useAllParams) is set to true, this parameter can be set in the InvokerLocator, the client's configuration map, or the metadata map passed to the Client.addConnectionListener() method. If failureDisconnectTimeout is set to an integer value other than -1, then ConnectionValidator will use that value when it calls the ClientInvoker.terminateLease() method, otherwise the value returned by the Client.getDisconnectTimeout() method is used.
    • JBREM-1111: In LeasePinger when all the TimerTasks that ran in java.util.TimerTask were shut down the Timer would also shut down and will not accept any further TimerTasks. If a new Timer was to be created and a TimerTask scheduled for it, an exception would occur. In order to successfully replace the Timer if it has shut down, the Wrapped timer.schedule() is now utilized.
    • JBREM-1110: The method org.jboss.remoting.InvokerLocator.getParameters() would return null if the URL had no parameters. In this updated release, the method returns an empty Map instead to ensure safer execution.
    • JBREM-1109: Within the org.jboss.remoting.MicroRemoteClientInvoker.getDataType() method when the dataType variable was set to the value of the getDataType(getLocator()) method, the variable would temporarily be set to null if the InvokerLocator had no datatype parameter. This caused issues because another thread may use the dataType variable and return a value of null. Correcting this bug has lead to using a local variable called localDataType while a check occurs to see if InvokerLocator contains a datatype value. The number of threads has also been reduced to 1000 in order to avoid an OutOfMemoryError that may have occurred.
    • JBREM-1104: When the org.jboss.remoting.ident.Identity.get() method would fail in a call to InetAddress.getLocalHost(), the runtime exception java.lang.RuntimeException: Exception creating identity: myhost: myhost would be generated. The issue was that the exception message did not give any information to the user concerning the underlying problem relating to the host name. This output has been fixed to display to the user the correct information in relation to the main host name issue.
    • JBREM-1102: A feature was requested that would make the configuration map available to the marshalFactory. In order to support this the new parameter org.jboss.remoting.Remoting.PASS_CONFIG_MAP_TO_MARSHAL_FACTORY has been added, which requires a setting of true in order to have the configuration map passed to the marshalFactory. If the parameter contains a value of false then the original behavior will be executed.
    • JBREM-1100: A feature was requested whereby ServerInvokerServlet instances could be linked to Connectors by MBean names rather than locator URLs. In order to achieve this the parameter org.jboss.remoting.transport.servlet.ServletServerInvoker.CREATE_UNIQUE_OBJECT_NAME has been added. When set to true, ServletServerInvoker.getMBeanObjectName() will call org.jboss.remoting.ServerInvoker.getMBeanObjectName() and return an ObjectName derived by the same algorithm that is used for all transports. To ensure the original default behavior remains, the default value is false.
    • JBREM-1099: The multicast detector did not work correctly in environments where many JBoss Remoting invokers were being used. The org.jboss.remoting.detection.AbstractDetector.createDetection() method would create a detection message based on the number of server invokers registered locally. In the JBoss Enterprise Application Server this would cause an error as the message size would exceed the 4000 limit. A buffersize attribute has been created for org.jboss.remoting.detection.multicast.MulticastDetector and org.jboss.remoting.detection.multicast.MulticastDetectorMBean that defaults to a value of 10000.
    • JBREM-1088: If the server hostname DNS mapping was not available at the client during a org.jboss.remoting.Client.connect() call, the org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName produces a java.net.UnknownHostException in relation to the hostname. However when the method MicroSocketClientInvoker(InvokerLocator locator, Map configuration) is called the exception is captured and then displayed using throw new RuntimeException(ex.getMessage()). By displaying the exception in this way, information important in understanding the cause of the exception, is lost. This has been rectified by changing throw new RuntimeException(ex.getMessage()); to throw new RuntimeException(ex.getMessage(), ex);, enabling the actual exception content to be displayed to the user.
    • JBREM-1085: The log level of the ServerSocketWrapper.close() method log messages has been reduced in order to remove unwanted information. Instead of using the log.debug() call, the method now uses log.trace().
    • JBREM-1084: When org.jboss.remoting.Client.addConnectionListener() created a CallbackPoller, a reference to itself and a metadata map would be passed. The issue arose from the CallbackPoller only accessing parameters in the metadata map. To rectify this issue the Client.USE_ALL_PARAMS parameter is checked within the InvokerLocator, the client's configuration map and the metadata map that is passed to the Client.addListener() method respectively. If the useALLParams property is found and set to a value of true, the InvokerLocator, the client's configuration map and the metadata map will be searched respectively for all parameters used by CallbackPoller, otherwise only the metadata map will be used, which is the default behavior.
    • JBREM-1082: When org.jboss.remoting.Client.addConnectionListener() created a ConnectionValidator, a reference to itself would be passed and the ConnectionValidator would access the client's configuration map. The issue arose from the client's configuration map not including the InvokerLocator parameters. To rectify this issue the ConnectionValidator now searches for the Client.USE_ALL_PARAMS parameter in the InvokerLocator, the client's configuration map and the metadata map that is passed to the Client.addConnectionListener() method respectively. If the useALLParams property is found and set to a value of true, the ConnectionValidator will search for parameter values in the InvokerLocator, the client's configuration map and the metadata map respectively.
    • JBREM-1081: When the method ServerInvokerCallbackHandler.destroy() shut down When org.jboss.remoting.callback.ServerInvokerCallback, the variables callBackClient and callbackStore were set to null. If the ServerInvokerCallbackHandler.handleCallback() is then called a NullPointerException arises because that variables callBackClient and callbackStore are set to null. This bug has been corrected in this latest release by the ServerInvokerCallbackHandler.destroy() method no longer assigning a value of null to the variables callBackClient and callbackStore.
JBoss Web
  • JBPAPP-2067: The release of Tomcat 6.0.20 saw a set of security vulnerabilities fixed that have now been backported to JBoss Web. These vulnerabilities are:
    • CVE-2008-5515: Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, 6.0.0 through 6.0.18, and possibly earlier versions normalized the target pathname before filtering the query string when using the RequestDispatcher method, which allowed remote attackers to bypass intended access restrictions and conduct directory traversal attacks via .. (dot dot) sequences and the WEB-INF directory in a Request. This update has been rated as having important security impact by the Red Hat Security Response Team.
    • CVE-2009-0783: Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18 would permit web applications to replace an XML parser used for other web applications. This would allow local users to read or modify the web.xml, context.xml, or tld files of arbitrary web applications via a crafted application that is loaded earlier than the target application. This update has been rated as having low security impact by the Red Hat Security Response Team.
    • CVE-2009-0580: For Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18, when FORM authentication was used, this would allow remote attackers to enumerate valid usernames via requests to /j_security_check. This would be achieved with malformed URL encoding of passwords, related to improper error checking in the MemoryRealm, DataSourceRealm, and JDBCRealm authentication realms, as demonstrated by a % (percent) value for the j_password parameter. This update has been rated as having low security impact by the Red Hat Security Response Team.
  • JBPAPP-2050: When attempting to view a mbean graph through the web-console an exception was being generated by the applet because the jcommon.jar library was not included within the ZIP version of the previous release. This library file is now included with this release and mbean graphs are now viewable through the web-console.
  • JBPAPP-1874: The JBoss Web component of the Enterprise Application Platform has been upgraded to version 2.0.0.CP10. A list of the included fixes is as follows:
    • JBPAPP-1992: Apache Tomcat 5 and 6 did not properly handle double quote (") characters and the encoded backslash (%5C) sequences in cookie values. These bugs may have allowed for sensitive information such as session IDs to be leaked to remote attackers and permit session hijack attacks. This has been rectified by the modification of ApplicationContext.java to generate a MalformedURLException if a path starts with an encoded backslash and the modification of ServerCookie.java to escape double quote characters. (CVE-2007-5333)
    • JBPAPP-1950: After the HttpServletResponse.reset method was executed, any subsequent calls to response.setContentType or response.setCharacterEncoding had no effect on the content type. This latest release incorporates a fix that allows the response.setContentType and response.setCharacterEncoding methods to function correctly after a HttpServletResponse.reset call and modify the content type. To achieve this outcome the following method executions have been added to the reset() method of the Response class:
      usingOutputStream = false;
      usingWriter = false;
      isCharacterEncodingSet = false;
      
    • JBPAPP-1873: When the LIMIT_BUFFER parameter was set to true an ArrayIndexOutOfBoundsException would occur. The BodyContentImpl.java file has been updated to correct this bug by removing the bufferSizeSave variable and removing the case where the writer variable isn't null. To replace these a case has been written to execute the clearBody method when the writer variable is equal to null. By implementing these changes the JspWriter buffer size and remaining bytes are calculated correctly, removing the ArrayIndexOutOfBoundsException.
JBoss Web Services
  • JBPAPP-1643: The JBoss Web Services component of the Enterprise Application Platform has been upgraded to version 2.0.1.SP2_CP06. A list of the included fixes is as follows:
    • JBPAPP-1974: The optimization within the JBossXSModel implementation for traversing a XML schema was insufficient, allowing for high deployment overhead when dealing with complex schemas. Correcting this has been a process of modifying the JBossXSModel.java file by adding calls to clear the HashSet periodically throughout the traversing process.
    • JBPAPP-1961: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced Denial of Service attacks on a server that accepts XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
    • JBPAPP-1956: The wscompile class would fail to create a valid package name when the namespace contained a capitalized reserved keyword. Rectifying this issue has seen the NameConverter.java file modified to include code that transforms all characters in the namespace to lower case. This fix also sees the upgrade of the JAXB component to 2.1.4.patch02; (see JBPAPP-1982 for reference).
    • JBPAPP-1773: Previously MTOM was only enabled for types annotated with @XmlMimeType where the content-type headers from the incoming messages should be sufficient to determine if MTOM is required. To fix this bug, MTOM has been enabled for incoming requests where the content type is application/xop+xml. To achieve this outcome both the MessageFactoryImpl.java and ServiceEndpointInvoker.java files have been updated to retrieve the message type and set the outbound context properties before calling the request handler chain respectively.
    • JBPAPP-1760: If a substantial amount of SOAP requests were received by the JBoss Enterprise Application Platform during application deployment the HandlerResolverImpl class would cause a ConcurrentModificationException. Though this would not cause the application to cease operation, it would result in the strange behavior of every request going only through the JAXWS handler twice and not go into service implementation. In order to correct this bug, the code responsible for initiating handler chains within the HandlerDelegateJAXWS.java and HandlerDelegateJAXRPC.java has been synchronized.
    • JBPAPP-1752: The fault handler was not being called when user application exceptions were being generated. The implementation of the fault handler has been reworked for this Cumulative Patch release to catch the application exceptions and all other kinds of exceptions.
    • JBPAPP-1749: The SPI component of JBoss Web Services has been upgraded to version 1.0.0.GA_CP02. A list of the included fixes is as follows:
      • JBPAPP-1750: SOAP 1.2 deployments are supported within JBoss Web Services, however the wsconsume tool does not support SOAP 1.2 bindings. To enable this tool to support SOAP 1.2, the files WSConsume.java and WSContractConsumer.java have been updated to recognize SOAP 1.2, while the files WSConsumeTask.java and SunRIConsumerImpl.java have been updated to set extensions.
    • JBPAPP-1746: Handler Chains did not work correctly within Dispatch clients causing incorrect behavior. The dispatch component of Web Services has undergone extensive correction so that it works as a user would expect it to.
    • JBPAPP-1743: WeakReferences handling within ConfigObservable was not handled correctly causing errors as the value of the WeakReferences became set to null. This has been corrected by adding a ReferenceQueue that identifies the references that require removal. These references are cleared only when a future registration or notification occurs.
    • JBPAPP-1732: The MTOM/XOP message always set the start-info property to text/xml when it should have been set to application/soap+xml. This bug was introduced through an upgrade from SOAP 1.1 to SOAP 1.2. The SOAP HTTP binding in the Content-type header has now been updated to the correct value.
    • JBPAPP-1688: The Common component of JBoss Web Services has been upgraded to version 1.0.0.GA_CP04. A list of the included fixes is as follows:
      • JBPAPP-1687: Each request to the Web Services component would result in an open file descriptor. This caused the application to reach the limit of the maximum amount of file descriptors allowed and then fails on every request after. This issue has been rectified by ensuring that all streams and file descriptors are closed within the different aspects of the Web Services component.
    • JBPAPP-1655: The Framework component of JBoss Web Services has been upgraded to version 2.0.1.GA_CP04. A list of the included fixes is as follows:
      • JBPAPP-1887: A bug existed within the wsprovide.bat file where there is no reference to jaxb-xjc.jar in the classpath. This issue has been corrected by adding the following line to the beginning of the wsprovide.bat file and thus adding jaxb-xjc.jar into the classpath:
        										set WSPROVIDE_CLASSPATH=%WSPROVIDE_CLASSPATH%;%JBOSS_HOME%/client/jaxb-xjc.jar
        
      • JBPAPP-1784: When starting the Enterprise Application Platform with the -Dcom.sun.management.jmxremote option, a NullPointerException would occur. The SubscriptionManager.java file was updated to allow for a break in the MBeanServer if the MBeanServer server class name starts with org.jboss.
    • JBPAPP-1644: WSDL schema imports did not successfully publish in earlier versions of the JBoss Enterprise Application Platform. Correcting this issue, the WSDLFilePublisher.java file has been updated with the return code changed to continue within the infinity loop prevention when the file being published contains a location URL or a schema location value.
    • JBPAPP-991: When deployment failed an endpoint could be left registered and undeployment would not remove this registration, forcing further deployments to fail. To fix this the ArchiveDeployerHook.java file was updated so that even in the event of a deployment aspect failing to deploy, all endpoints will still be called on undeployment in order to ensure registration removal.
    • JBPAPP-829: Authentication and authorization needed to be added for POJO endpoints where credentials are supplied using Web Services Security. In order to rectify this issue the following list of files were updated or added as specified:
      • ReceiveUsernameOperation.java was updated with the removal of the operations for the Logger to acquire information about the username and password of the current user variable value.
      • WSSecurityOMFactory.java was updated with new methods for parsing characters and elements as well as the public method setValue which passes a value to the role.setName method and a test if authorization is necessary for the current localName.
      • Config.java has been updated to include a private Authorize class as well as the public methods getAuthorize() and setAuthorize().
      • AuthorizeOperation.java has been added to authenticate and check the authorization of the current user.
      • SecurityDecoder.java has been updated to also use the new classes Authorize and AuthorizeOperation.
      • ClientImpl.java has been updated to include a value of false as the last property of the new HandlerChainExecutor being created.
      • HandlerChainExecutor.java has been updated in order to determine specific client side conformance requirements.
      • Role.java has been added in order to provide a role in the program which is authorized to call an endpoint.
      • Authorize.java has been added in order to ensure that a user is authorized to call the endpoint.
      • WSSecurityDispatcher.java has been updated to remove the SecurityStore creator and now include private methods to decode the header and test authorization.
      • DispatchImpl.java has been updated to include a value of false as the last property of the new HandlerChainExecutor being created.
      • HandlerDelegateJAXWS.java has been updated to include a value of false as the last property of the new HandlerChainExecutor being created.
JGroups
  • JBPAPP-2002: The JGroups component of the Enterprise Application Platform has been upgraded to version 2.4.6. A list of the included fixes is as follows:
    • JGRP-975: The JGroups testsuite did not permit a user to specify host and port properties for the GossipRouter implementation. This meant that the IP address was fixed at 127.0.0.1 and the port was fixed at 12001. This update allows for the host and port properties to be configurable so that the system can be tested against other values other than only the defaults.
    • JGRP-961: Running the JGroups testsuite against IPv6 addresses using link-local IPv6 addresses with no zone ID would cause some tests to fail that would normally pass when run against IPv4 addresses. The problem arose if the zone ID was omitted and the OS assigned a default interface to send the message, which may not have been the one the user was after. To correct this issue so that IPv6 addresses worked correctly with JGroups, scoped link-local addresses had to be used with the ServerSocketReceiver and ServerSocketSender classes, enabling use of the correct zone ID in each IPv6 address case.
    • JGRP-949: Format version information was not displayed to the user in the most meaningful way. In order to make sure the the user receives the most useful information the way in which the format version information is provided has changed from:
      log.warn(new StringBuffer("packet from ").append(client_addr).append(':').append(client_port).append(" has different version (").append(version).append(") from ours (").append(Version.version).append("). This may cause problems"));
      
      To:
      log.warn(new StringBuffer("packet from ").append(client_addr).append(':').append(client_port).append(" has different version (").append(version).append(") from ours (").append(Version.print(Version.version)).append("). This may cause problems"));
      
      Of note is the change of Version.version to Version.pring(Version.version).
    • JGRP-923: GMS address printing did not contain the cluster name in the details it provided. For this Cumulative Patch release GMS address printing has been updated to include the cluster name in order to provide more detail to a user.
    • JGRP-893: Previously JGroups could not parse IPv6 addresses in the stack configuration correctly as it used a double colon (::) as a delimiter. These characters are now parsed correctly in JGroups so that IPv6 addresses can be used in a stack configuration correctly.
JBoss Hibernate
  • JBPAPP-2118: The Hibernate EntityManager component of the Enterprise Application Platform has been upgraded to version 3.3.2. A list of the included fixes is as follows:
    • EJB-341: If a user attempted to create a named query that did not exist, a PersistenceException would be generated where an IllegalArgumentException should have been raised, and the current transaction would be rolled back. The AbstractEntityManagerImpl class has been updated to catch the MappingException and return an IllegalArgumentException to the user, as well as attempt to return a new named query using QueryImpl.
    • EJB-340: The onLoad method was not invoked on an EJB3Interceptor, though it was in the basic Hibernate environment. This issue has been fixed by editing the EventListenerConfigurator class to include the default Hibernate Core PreLoadEventListener.
    • EJB-333: A space was present in the path during deployment within the JBoss Enterprise Application Platform and this space would cause an error. In order to fix this, the ExplodedJarVisitor, FileZippedJarVisitor and JarVisitorFactory classes have been updated to cater for a space in a java URL file name.
    • EJB-330: If the Ejb3Configuration had classes that contained @PostLoad callbacks and had been added with the addAnnotatedClass method, these would no longer work if the configure method was executed before the addition of @Entity-annotated classes, through the use of the addAnnotatedClass method. This bug has been fixed by delaying the call to the configure method in order to allow for the correct addition of all annotated classes.
    • EJB-326: The persistence unit root that exists in a .war file was not being correctly handled. This issues has been fixed by changing the way in which the EJB3 submits the persistence root URL to Hibernate.
    • EJB-325: The Ejb3Configuration class has been updated to ensure that PersistenceExceptions state the persistenceUnit that is generating the exception.
    • EJB-316: The PERSISTENCE_PROVIDER string should be coded as a final string type. The Persistence class has been updated for this release to include the PERSISTENCE_PROVIDER string as a final string type.
    • EJB-305: As a new feature, a configuration option has been added that grants the ability to define a session scoped interceptor through the use of the hibernate.ejb.interceptor.session_scoped property.
    • EJB-299: If a package-info.class attribute existed within the default package the JarVisitor.addElement method would fail and generate a StringIndexOutOfBoundsException. Updating the AbstractJarVisitor class so that if the name length of the entry is set it the length of the package-info.class attribute, the name is left blank, otherwise the name property is the length of the entries specified name.
    • EJB-284: A bug existed within the ArchiveBrowser where it would not abstract a file path for orm.xml correctly when Hibernate was run on the Windows operating system. In this new version of Hibernate EntityManager, the ArchiveBrowser has been replaced with the JarVisitor. This process has caused this issue to be fixed.
    • EJB-282: The ORM.xml file was being ignored when the excludeUnlistedClass property was set to true in the container mode. This bug has been rectified by modifying the Ejb3Configuration class to ensure that the ORM.xml file is searched even when the excludeUnlistedClass property is set to true.
    • EJB-277: String values could not be used as query hint values within Hibernate. This functionality has now been added to Hibernate EntityManager by modifying the ConfigurationHelper class to accept string values and the QueryImpl class to utilize these changes.
    • EJB-275: Since IBM WebSphere does now return an encoded URL from the cl.getResources method, the JarVisitor would fail due to white space errors. The JarVisitor class has now been updated to ensure that URLs returned by IBM WebSphere is striped of any white space that may cause the program to produce an error.
    • EJB-271: The EJB3OverridenAnnotationReader class has been improved by raising a warning when deployment descriptors refer to an unknown property. This has been achieved by checking for orphan properties.
    • EJB-269: Hibernate EntityManager would fail to deploy a persistence archive in the Weblogic Server. This issue has been rectified by including a .jar file for archive browser handling for the Weblogic Server.
    • EJB-266: Hibernate would initialize lazy objects that were being traversed by the persist operation. This release sees the Hibernate EntityManager avoid collection loading during a cascaded persist, allowing for increased performance on heavily cascaded object graphs.
    • EJB-263: Within the QueryImpl class, elements were not being made unique before getSingleResult method exceptions were being raised. This allowed for a NonUniqueResultException to be generated incorrectly. For this release, elements within the QueryImpl class are now made unique before any getSingleResult method exceptions are raised.
    • EJB-262: An improvement has been made to the Ejb3Configuration class that provides the XML file name when a parsing error occurs. In completing this task the new class NamedInputStream has been created.
    • EJB-259: ORM.xml files that appear in any referenced .jar files were not evaluated by Hibernate EntityManager. In order to be in line with the EJB3 specifications, the Ejb3Configuration class has been updated to make sure all ORM.xml files are evaluated.
    • EJB-257: The EJB3Configuration class should be able to work successfully without needing to use any configure methods. This update allows for the EJB3Configuration class to work correctly without the need for any configure methods by copying the programmatically defined properties and using them with the new AnnotationConfiguration.
    • EJB-242: The InputStreamZippedJarVisitor class has been updated to produce an exception instead of an IO exception so that Eclipse does not produce a NullPointerException but instead just logs a warning message. This allows for Hibernate and Eclipse to function easier together.
    • EJB-46: The PrePersist callback method was not being utilized if the primary key of the entity was set to null. The way in which the Hibernate EntityManager would operate when a primary key of the entity was set to null has been changed so that the PrePersist callback method can be correctly utilized.
  • JBPAPP-2110: The Hibernate Validator component of the Enterprise Application Platform has been upgraded to version 3.0.0. A list of the included fixes is as follows:
    • HV-10: The Luhn algorithm has been implemented in Hibernate Validator and the @CreditCardNumber interface created. The Luhn algorithm implementation requires a valid credit card number and checks for user error. This class does not check for credit card validity.
    • HV-9: The @Digits interface has been added to Hibernate Validator. This interface allows for digits to be expressed as integers and fractions. This new interface resides within the Digits.java file.
    • HV-8: Hibernate Validator now supports pure JavaPersistence players. Though when used through EntityListeners, parameters such as interpolator are not supported due to the listener lifecycle not being defined and no avenue exists to pass the PU properties.
    • HV-7: Two level @Valid annotation did not work as a user would have expected. A NullPointerException would be generated when initialization occurred in the ClassValidator. This bug has since been fixed by initializing the reflectionManager within the ClassValidator constructor.
    • HV-6: The @EAN annotation type has been added to Hibernate Validator. This element checks if the string is a correctly formated EAN-13 or UPC-A code; it does not check for number validity.
    • HV-5: The ability to have multiple validators of the same type for each element has been added to Hibernate Validator. Though Hibernate Validator could already achieve this functionality to an extent, this improvement allows for greater ease of use for the user.
    • HV-3: The @Email validating string would fail if the string contained a null value. The EmailValidator class has been modified to include checking for a null value and to handle this case correctly so that the validation does not fail.
    • HV-2: String support for both @Past and @Future validating Strings has been deprecated as there was no absolute way to be sure of the date and time format or the locale that may be used.
    • HV-1: A new feature has been added to Hibernate Validator that sets the ClassValidator as being independent of Hibernate Annotations. This ensures that if a users wishes, Hibernate Validator does not have to be used with Hibernate Annotations.
  • JBPAPP-2037: The Hibernate Core component of the Enterprise Application Platform has been upgraded to version 3.2.4.SP1_CP08. A list of the included fixes is as follows:
    • JBPAPP-1930: A NullPointerException would occur when a native SQL query coupled eager fetching with a many-to-many relationship. Correcting this has meant that the if ( collectionPersister.isOneToMany() ) { line of code in the SQLQueryReturnProcessor file has been changed to if ( collectionPersister.isOneToMany() || collectionPersister.isManyToMany()) {, removing the generation of a NullPointerException. To note though is that the fix only works with the hbm.xml file SQL mapping feature and a named query.
    • JBPAPP-1922: A bottleneck existed within the EntityModeToTuplizerMapping.java file when a high number of threads attempted to initialize sets and had to wait for the same monitor. In correcting this issue, the EntityModeToTuplizerMapping.java file has been modified to remove the private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() ); line of code and replace it with only private final Map tuplizers; and two new public methods to assist in the mapping.
    • JBPAPP-1797: Transient entities could be inserted twice when a merge was performed. To correct this bug the DefaultMergeEventListener.java file has been updated to use the new CopyCache class. Within the DefaultMergeEventListener.java file, logic has been added to retrieve transient entities and retry a merge once if an error is encountered. Following this, if the merge continues unsuccessfully a TransientObjectException will be generated. The CopyCache class has been created to be the Map implementation used by DefaultMergeEventListener in order to keep track of entities and the copies that are being merged into the session. This implementation also tracks whether a an entity in the CopyCache is included in the merge.
    • JBPAPP-1748: When merging read-only entities that had the @Immutable annotation included the following failure would occur:
      	
      org.hibernate.AssertionFailure: Merged entity does not have status set to MANAGED; EntityEntry[com.tll.model.impl.AccountHistory#71794688](READ_ONLY) status=READ_ONLY
      
      The DefaultMergeEventListener.java file has been updated by editing the following test statement:
      if ( entry.getStatus() != Status.MANAGED ) {
      	throw new AssertionFailure( "Merged entity does not have status set to MANAGED; "+entry+" status="+entry.getStatus() );
      }
      
      modified to test against the possibility that the current Status could be READ_ONLY:
      if ( entry.getStatus() != Status.MANAGED && entry.getStatus() != Status.READ_ONLY ) {
      	throw new AssertionFailure( "Merged entity does not have status set to MANAGED or READ_ONLY; "+entry+" status="+entry.getStatus() );
      }
      
    • JBPAPP-1564: The SQL trim function and support for mod and bit_length were not present in the Sybase Dialect. This release sees these available for use within the SybaseASE15Dialect.
    • JBPAPP-1563: The SQL functions mod, bit_length and trim caused failures in the ASTParserLoadingTest because they were not implemented in the Sybase Dialect. The Sybase Dialect has now been updated to import the org.hibernate.dialect.function.AnsiTrimEmulationFunction function and implement the mod, bit_length and trim functions.
  • JBPAPP-2078: The Hibernate Annotations component of the Enterprise Application Platform has been upgraded to version 3.3.1. A list of the included fixes is as follows:
    • ANN-701: The error message given when using the @CollectionId property incorrectly did not give useful information to the user. Correcting this, the CollectionBinder.java file has been updated to generate an exception with all relevant information given the improper use of the @CollectionId property for individual cases.
    • ANN-700: The NamedQuery class of Hibernate had the flushMode attribute set to AUTO by default. This caused inconsistencies throughout the program and the flushMode attribute to never contain the correct value. To correct this the default value of the flushMode attribute is now set to a newly introduced PERSISTENCE_CONTEXT. This new value makes sure that the flushMode is consistent with the persistence context at the time the query is executed, alleviating inconsistency issues.
    • ANN-699: The AnnotationBinder.mustBeSkipped contains a hardcoded reference to the org.hibernate.tool.instrument.javassist.FieldHandler class. The issue that arises from this is that the class is actually contained within a different package and by having the incorrect reference it caused all javassist-instrumented classes to not function correctly. In order to rectify this issue the reference to the FieldHandler class has been changed within the AnnotationBinder.mustBeSkipped method to be org.hibernate.bytecode.javassist.FieldHandler.
    • ANN-698: Having an unbound property when default field access is used would lead to an unbound AnnotationException. The generated exception is now caught by the program and a more meaningful AnnotationException is generated and displayed to the user instead. These changes have been made to the AnnotationBinder class.
    • ANN-696: When a Hibernate map existed that had both key and value elements, the @Type annotation would affect both. To generate desired results the MapBinder.java and MapKey.java files have been updated to include and use a MapKey @Type.
    • ANN-695: New Hibernate Search collection even listeners have been integrated with the addition of the new classes CollectionSearchConfiguration and SearchConfiguration, and the amendment of the AnnotationConfiguration class to use the new SearchConfiguration class instead of embedding the search functionality within the AnnotationConfiguration.
    • ANN-694: An incorrect report of a Foreign Key circularity error was occurring when the @*ToOne property name started with the identifier property name. The issue has been fixed by modifying the ToOneFkSecondPass.java file to make the ToOneFkSecondPass method a public method.
    • ANN-690: Previous releases did not allow for method chaining within the AnnotationConfiguration class. This functionality has now been added by overriding all relevant configuration methods that reside within the AnnotationConfiguration class.
    • ANN-683: When hashCode collisions occurred within AnnotationConfiguration, random binding failures would occur. To fix this issue, the FkSecondPass.java file has been updated to use a unique counter in order to differentiate between two instances of FkSecondPass so that they can be compared as the IBM VM would sometimes return the same hashCode for two different objects. The AnnotationConfiguration.java file has also been updated to utilize the changes made to FkSecondPass.java.
    • ANN-673: AnnotationConfiguration did not define stable ordering for foreign key columns, allowing them to appear in any order within a generated SQL schema. Also of issue was when the hbm2ddl tool was being used to see a generated schema. The ordering of a foreign key column within a table could change if an unrelated modification was made inside the mapping of a different table. This issue was fixed by the solution for ANN-683 that is specified within these release notes.
    • ANN-671: When the Validator was not present, a message describing this would be logged, however this would occur twice. In this update the AnnotationConfiguration class has been modified to only log the occurrence of this once for each time.
    • ANN-653: The ability to use @AssociationOverride when overriding a collection delivered undesired results in the form of an exception. This functionality has now been fixed and works as expected.
    • ANN-650: In previous versions the @Version class could be set within an @Embedded class without any checking and generate a java.lang.ArrayIndexOutOfBoundsException that would not display enough detail about the error for a user to understand the cause. This has since be altered to check for this occurrence and generate an AnnotationException with useful information so that a user can correct any issues.
    • ANN-648: The o.h.a.Table.comment and o.h.a.Table.indexes methods would fail when used on secondary tables. To correct this issue the SecondaryTableSecondPass class has been updated to use the XAnnotatedElement class and the EntityBinder class now sets the secondary table as the first for when a join needs to occur.
    • ANN-637: The Table.appliesTo method would incorrectly select the last table when no matching table to the user query exists. This bug has been fixed by allowing the hibTable variable within the EntityBinder class to contain a value of null when the correct table cannot be found.
    • ANN-634: The @CollectionOfElements property would clash with the @Fetch JOIN, @Filter and @Where properties within the CollectionBinder class. The class has now been updated to test for the instance of a SimpleValue in the @CollectionOfElements property, correcting the issue.
    • ANN-633: The MANIFEST.MF file in the hibernate-annotation JAR file has been improved to contain vendor and versioning information using the default attributes defined in the JAR file specification.
    • ANN-621: A problem was being caused by the embedded primary key for ManyToOne associates containing only transient member variables. This was corrected by adding getter and setter accessors for the respective ID fields and setting both insertable and updatable properties to false.
    • ANN-619: When @OneToOne was placed within a composite key, the Hibernate application would generate an ExceptionInInitializerError. This has been fixed by recoding how a user application that does not use a true OneToOne relationships tested.
    • ANN-617: A NullPointerException would occur when a property of a composite ID would be used for ordering. This bug has been fixed by modifying the CollectionBinder class to check if the PersistentClass is null before checking if it is not an associatedClass.
    • ANN-613: A NullPointerException would be generated when the mappedBy property was incorrect in a @OneToOne mapping. In order to make sure a NullPointerException does not occur, when the otherSideProperty parameter contains a null vale within the OneToOneSecondPass class, an AnnotationException is generated detailing that the mappedBy property is incorrect and where.
    • ANN-608: A bug existed within the EJB3OverridenAnnotationReader class where the annotationsMap would not be correctly initialized, causing a NullPointerException in the AnnotationConfiguration class. The issue has been fixed by modifying the EJB3OverridenAnnotationReader.java file to remove an internal Annotation for loop and replace it with the code annotationsMap = new HashMap<Class, Annotation>( annotations.length + 5 ); instead. This change now allows for the annotationsMap to be correctly initialized.
    • ANN-606: The @Immutable annotation would not generate a configuration error or warning when used on a subclass. When @Immutable is not used on a root entity, a warning is now generated to inform the user of this incorrect behavior.
    • ANN-602: Any SecondaryTable with an EmbeddedId or IdClass containing a ManyToOne attribute would error. In order to fix this a new SecondaryTableSecondPass class has been created and the AnnotationConfiguration and AnnotationBinder classes have been updated to make use of the new class since associations can be built on joins. Implementing these changes causes the SecondaryTable class to behave as a user would expect.
    • ANN-590: An alphabetical ordering issue caused errors when the @ManyToOne and referencedColumnName properties were being used in the PrimaryKey. To correct this the ToOneFkSecondPass.java file was updated to try using an embedded property for a persistentClass.
    • ANN-567: No avenue existed to set the collectionPersister property on a Collection via Annotations. The functionality to be able to achieve this has now been added for this release.
    • ANN-560: Quoting issues existed with the default values in the NamingStrategy interface. In order to rectify this, the Ejb3JoinColumn.java and TableBinder.java files have been updated to quote the result and unquote the source before any other action is taken if the source is quoted.
    • ANN-559: An undefined filter definition would lead to a NullPointerException instead of generating a meaningful exception. This has been changed for the release so that this circumstance does not arise, instead a default filter definition is applied if one is undefined.
    • ANN-556: The @OneToOne relationship relied on strict alphabetical ordering that caused the mappedBy property to fail. The AnnotationBinder and AnnotationConfiguration classes have been updated to make sure that the OneToManySecondPass is processed in order.
    • ANN-555: A typo existed within the Tables class whereby the interface declaration contained Table[] values(); instead of Table[] value();. This small bug has been fixed for this release, allowing the Tables.value method to function correctly.
    • ANN-554: A NullPointerException would be generated when the @Id property was used on a @OneToOne relationship. Correction of this bug has been handled by modifying the OneToOneSecondPass class to avoid a NullPointerException in this case and instead generate a meaningful AnnotationException.
    • ANN-553: The classpath dependency (hibernate-validator.jar) file between Hibernate Annotations and Hibernate Validator has been removed and the ejb3-persistence.jar file has become a required dependency.
    • ANN-552: A major new feature for Hibernate Annotations is the transparent event registration and integration for Hibernate Search and Hibernate Validator if they are in the classpath.
    • ANN-551: Columns in a SQL insert query have to be ordered in the same way that Hibernate internally sorts its properties in order for the query to be successful. This was an issue for users as some would use numerous application servers, all of which would order these properties in different ways. The issue has been solved by modifying the AnnotationBinder class so that the parameters of a query are ordered internally to the order that Hibernate supports.
    • ANN-549: When an association table is involved in a table join, the key column would be set to null. The correct behavior is to have this key column forced to be not null. This has been achieved by modifying the MapBinder class to test if the collection is anything but a OneToMany relationship then the key column should not be null.
    • ANN-544: The CollectionBinder class used the setCustomSQLDelete method when testing if the sqlDeleteAll method was not null. This would prevent the execution of the col.clear method on the collection in the case that all the elements are removed. The functionality of CollectionBinder has been updated to now use the setCustomSQLDeleteAll method to ensure correct operation.
    • ANN-542: The @Immutable annotation has been added for entities and collections. This has seen the modification of the CollectionBinder and EntityBinder classes, as well as the addition of the new Immutable class.
    • ANN-535: When the @Generated annotation is used, the ability to insert and update a property should be forced. This improvement has been made to Hibernate Annotations through modification of the PropertyBinder class.
    • ANN-532: The exception handling of the @UniqueConstraint has been improved for cases when it refers to an incorrect column name. This has been achieved through the modification of the AnnotationConfiguration and Mappings classes.
    • ANN-529: Hibernate used the optional keyword as in the from clause within the MapBinder class. This behavior caused Hibernate Annotations to not be compatible with Oracle 10g. The optional keyword is now removed from the from clause and Hibernate Annotations is successfully compatible with Oracle 10g.
    • ANN-525: The @ForeignKey annotation that is used to specify readable names to foreign key constraints could not be applied at the class level and so could not be utilized in providing readable names to constraints between the super and sub classes using the InheritanceType.JOINED property. In this release the @ForeignKey annotation is now supported at the class level for all joined subclasses and is an attribute of the o.h.a.Table for secondary tables.
    • ANN-517: The EntityMode.DOM4J value would only work when a .hbm.xml mapping file is create and could not be used when only Hibernate Annotations was being used in business entities. The EntityBinder, PropertyBinder and CollectionBinder classes have been updated so that they call the setNodeName method. The error was that this was not being done by the AnnotationBinder, causing the Dom4j tuplizer to not be instantiated when only Hibernate Annotations was being used.
    • ANN-516: The @OrderBy attribute would be added to the incorrect table when used in an inheritance relationship. Condition testing has been added to the CollectionBinder class, ensuring that if the tables PersistentClass does not contain a value of associatedClass, the tables quoted name is retrieved; otherwise the table is assumed to be empty.
    • ANN-515: Fields were not correctly quoted in a @OneToMany relationship when they were specified, leading to a SQLGrammarException. The Ejb3JoinColumn.java file has been amended to use the method column.getQuotedName in the linkValueUsingAColumnCopy method, instead of column.getName.
    • ANN-509: Using a foreign key value for the referecedColumnName value would cause a MappingException to occur. The reason for this issue has stemmed through the need for correct ordering of steps and to fix this a RecoverableException class has been created which is used to catch the exception and allow the program to perform passes to assist in correcting the issue. If however this is unsuccessful then the loop is exited and the original exception is displayed to the user.
    • ANN-505: Support for the @Tuplizer annotation and interface annotations has been added to Hibernate Annotations. A tupilizer manages a particular representation of a piece of data, given the EntityMode of the representation.
    • ANN-502: Integration with Hibernate Validator was not completely possible as it is used in metamodel construction and could not be disabled. In order to allow for this functionality the hibernate.validator.apply_to_ddl has been added and can be set to false to remove Hibernate Validator integration with metamodel construction.
    • ANN-444: In Hibernate Core, the <join> tag in .hbm.xml files contain an attribute called optional that allows for configuration of Hibernate to either use inner joins or outer joins, however this same functionality was not included in Hibernate Annotations. This feature has now been added to Hibernate Annotations through the modification of the EntityBinder and Table classes.
    • ANN-442: Support for more than one generic generator in the package-info.java file has been added by adding the new GenericGenerators interface, and updating the AnnotationBinder to incorporate the use of the new interface.
    • ANN-434: The exception that was generated when attempting to create an entity with an EmbeddedId and automatically generated IDs did not give useful information to a user. This has been corrected by modifying the AnnotationBinder class to generate an AnnotationException that outputs the class name of the component with information explaining that this class must not have ID properties when used as an EmbeddedID.
    • ANN-252: The AnnotationConfiguration class would ignore classes that were annotated with an incorrect Entity or contained no annotation. The AnnotationBinder class has been updated to log a warning message if any of the mentioned circumstances occurs.
    • ANN-122: The @NaturalId annotation that was added to Hibernate previously, has now been added to Hibernate Annotations. This allows for a property to be specified as part of the natural id of an entity.
    • ANN-104: CRUD SQL customization is now allowed on secondary tables within Hibernate Annotations.
    • ANN-103: The ability to specify a fetching strategy for a secondary table has been added to Hibernate Annotations.
    • ANN-28: The @Any and @ManyToAny mapping values have been added as a new feature to Hibernate Annotations. With these features added, it allows for a more robust and diverse database environment.
    • ANN-26: Support for the ability to exclude a property from the optimistic locking has been added to Hibernate Annotations.
  • JBPAPP-2032: The Hibernate Annotations upgrade that has occurred between the last JBoss Enterprise Application Platform Cumulative Patch and this one may cause backwards-compatibility issues for some users due to the changes introduced to applications that use SchemaExport in production. The following instances are circumstances where an issue may arise:
    • Users who rely on the hbm2ddl component of Hibernate Annotations must now check their manually created indexes as there is a high possibility that the order of these will have to change to avoid a performance penalty. An example of this would be that if the index was B, A and Hibernate Annotations now queries based on A, B then the index will not be used.
    • Users who rely on custom Hibernate CRUD operations are required to manually check if their SQL is up-to-date. An example of when this would be required is if a user has a table with the structure NAME(string), FK1(int), FK2(int) and the FK's point to a table which has overlapping or the same ID set. With this Hibernate Annotations upgrade it is now assumed that the structure is NAME(string), FK2(int), FK1(int). This change will not cause CRUD operations to fail at runtime but the semantics of the update will be incorrect.

    Warning

    If these concerns are not addressed by affected users then noticeable data consistencies and performance issues may arise. The new configuration parameter hibernate.legacy.foreignkey.use_identity_hashcode_to_compare should also not be utilized as it will restore indeterminate behavior.
  • JBPAPP-1859: The ManyToOneJoinTest distributed with Hibernate would fail because a primary key would be set on a nullable column. The OneToOneSecondPass.java file has been modified to use the buildJoinFromMappedBySide method instead of the buildJoin method. Enacting this change has meant that the calls to the join.createPrimaryKey() and join.createForeignKey() methods within this file have also been removed.
  • JBPAPP-1081: In the Entity Manager documentation it is stated that table aliases are supported in update clauses, however using table alias' in an update query causes a program failure. In order to correct this the QueryTest.java file has been updated with the removal for the allowance of table alias'.
JBoss Transaction Service (JBossTS)
  • JBPAPP-1693: The JBoss Transaction Service component of the Enterprise Application Platform has been upgraded to version 4.2.3.SP5.CP05. A list of the included fixes is as follows:
    • JBPAPP-1684: A memory leak would be caused in the BaseTransaction class because entries in the hash table were never removed, even if a thread was no longer in use. This meant that client transactions could have leaked approximately 600 bytes. To correct this bug, the BaseTransaction.java file has been updated to replace the hash table with a ThreadLocal implementation which takes an integer as input. In order to allow for the timeout values to work correctly, they now only call the required methods of _timeouts.set and _timeouts.get. With these improvements made, the memory leak no longer occurs.
Security Issues
  • JBPAPP-2067: The release of Tomcat 6.0.20 saw a set of security vulnerabilities fixed that have now been backported to JBoss Web. These vulnerabilities are:
    • CVE-2009-0033: For Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18, when the Java AJP connector and mod_jk load balancing were used it would allow for remote attackers to cause a denial of service (application outage) attack via a crafted request with invalid headers. This would occur in relation to the temporary blocking of connectors that had encountered errors, as demonstrated by an error involving a malformed HTTP Host header. This update has been rated as having important security impact by the Red Hat Security Response Team.
    • CVE-2008-5515: Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, 6.0.0 through 6.0.18, and possibly earlier versions normalized the target pathname before filtering the query string when using the RequestDispatcher method, which allowed remote attackers to bypass intended access restrictions and conduct directory traversal attacks via .. (dot dot) sequences and the WEB-INF directory in a Request. This update has been rated as having important security impact by the Red Hat Security Response Team.
    • CVE-2009-0783: Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18 would permit web applications to replace an XML parser used for other web applications. This would allow local users to read or modify the web.xml, context.xml, or tld files of arbitrary web applications via a crafted application that is loaded earlier than the target application. This update has been rated as having low security impact by the Red Hat Security Response Team.
    • CVE-2009-0781: A Cross-site scripting (XSS) vulnerability existed within the jsp/cal/cal2.jsp calendar examples web application for Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18. This vulnerability would allow remote attackers to inject arbitrary web script or HTML via the time parameter, related to invalid HTML. This update has been rated as having low security impact by the Red Hat Security Response Team.
    • CVE-2009-0580: For Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18, when FORM authentication was used, this would allow remote attackers to enumerate valid usernames via requests to /j_security_check. This would be achieved with malformed URL encoding of passwords, related to improper error checking in the MemoryRealm, DataSourceRealm, and JDBCRealm authentication realms, as demonstrated by a % (percent) value for the j_password parameter. This update has been rated as having low security impact by the Red Hat Security Response Team.
    These bug fixes are part of the JBoss Web 2.0.0.CP10 upgrade.
  • JBPAPP-1992: Apache Tomcat 5 and 6 did not properly handle double quote (") characters and the encoded backslash (%5C) sequences in cookie values. These bugs may have allowed for sensitive information such as session IDs to be leaked to remote attackers and permit session hijack attacks. This has been rectified by the modification of ApplicationContext.java to generate a MalformedURLException if a path starts with an encoded backslash and the modification of ServerCookie.java to escape double quote characters. (CVE-2007-5333)
    This bug fix is part of the JBoss Web 2.0.0.CP10 upgrade.
  • JBPAPP-1961: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced Denial of Service attacks on a server that accepts XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
    This bug fix is part of the JBoss Web Services 2.0.1.SP2_CP06 upgrade.
Documentation
  • JBPAPP-2011: Documentation which explains how to achieve POJO Endpoint authentication in this latest CP release, has been incorporated into the Server Configuration Guide. This information can be found in section 10.13. POJO Endpoint Authentication and Authorization.
  • JBPAPP-1782: Chapter 7.2 named Adjusting memory settings within the Installation Guide, stated that a user should modify the run.conf file in order to increase the available memory to the program. This however is incorrect when running the JBoss Enterprise Application Platform on a Windows operating system. In this case the run.bat file should be modified and the documentation now reflects this difference.
  • JBPAPP-1689: The Server Configuration Guide, section 16.5 contained an error regarding the name of the directory where JBoss Web is deployed. Instead of the path to the jboss-service.xml file being JBOSS_HOME/server/all/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml it should be JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml. For this CP release, the file path has been corrected.
  • JBPAPP-1584: Information about the LdapExtLoginModule was missing from the documentation on login modules within the Server Configuration Guide. The information about this module has now been added to the Using JBoss Login Modules section of the guide.
Core Server
  • JBPAPP-1976: The HASingletonElectionPolicySimple class of the Clustering component retrieved the current view from the HAPartition and formulated a decision based on that information that ignored the possibility that the service being managed may not be running on all cluster members. To fix this issue the ExtendedElectionPolicySimple class has been created and when used it fixes not only the above issue but also an issue where using the kill -9 command was necessary to start singletons on other nodes. This new class extends the election policy and provides helper methods for stable implementations.
  • JBPAPP-1932: Java 1.4 based clients would not function when trying to use the Java remote method invocation interface over the Internet Inter-Orb Protocol (RMI-IIOP). This occurred because sections of placeholder code (which allow the program to function correctly) were needed, however these sections of code were compiled with Java 1.5 without compatibility for version 1.4. In order to correct this bug, the iiop/build.xml file has been updated with the removal of:
    <javac destdir="${build.classes}/main"
           optimize="${javac.optimize}"
           target="${javac.target}"
           source="${javac.source}"
    
    and replaced with:
    <javac destdir="${build.classes}/main"
           optimize="${javac.optimize}"
           target="1.4"
           source="1.4"
    
    forcing the build.xml file to use Java 1.4.
  • JBPAPP-1685: Apache-slide has been upgraded to version 2.1.jdk15-brew. In this change is the renaming of jakarta-slide-webdavlib.jar to webdavlib.jar and the commons-httpclient.jar has been removed from the distribution because it was dependant on an excluded commons-codec.jar. Removal of the commons-httpclient.jar file does not impact correct functioning of the JBoss Enterprise Application Platform.
  • JBPAPP-1100: hsqldb has been upgraded to version 1.8.0.8.patch02-brew. In this change is a change to the MANIFEST.MF file. In previous releases the version information was displayed as a timestamp, an example would be:
    private-2007/12/18-11:59:06
    
    This release correctly shows the version of hsqldb correctly within the MANIFEST.MF file as:
    1.8.0.8.patch02
    

9.  Known Issues with this release

Following is a list of known issues at the time of release.
General Known Issues
  • JBPAPP-1774: The JBoss Enterprise Application Platform RPM cannot be installed with only the OpenJDK distribution.
  • JBPAPP-1286: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a documented issue is automatically generated as a footnote and places a number beside that of the documented issue, referencing a footnote that does not appear.
Hibernate Known Issues
  • JBPAPP-1709: The JPA spec defines the constant with a value that has a typo in the class name:
    javax.persistence.Persistence.PERSISTENCE_PROVIDER = "javax.persistence.spi.PeristenceProvider"
    
    The version of ejb3-persistence.jar released in EAP is non-compliant with the JPA spec because it sets the correct classname (without the typo) for this constant.
    Javadoc for javax.persistence.Query.getSingleResult() says that the EntityNotFoundException will be generated if there is no result. The Javadoc should have mentioned the NoResultException instead.
  • JBPAPP-953: Hibernate Core and Annotations do not currently support the Hypersonic 1.8.0.8 database. Support for the version 1.8.0.8 of the Hypersonic database is no longer planned for future releases.
Messaging Known Issues
  • JBMESSAGING-1682: By increasing the allowed number of servers that are connected to a single host to 65535 in the JBMESSAGING-1614 feature update, a unique key violation can occur. If the sending rate of messages within one node is equal to or greater than 32767 messages per millisecond (short.MAX_VALUE), and those messages are all stored in the database at the time, this leads to a circumstance where two messages may have identical ID numbers.

A. Revision History

Revision History
Revision 1.0