7.  Issues fixed in this release

Following is a list of issues fixed in this release:
Security Issues

  • JBPAPP-3952: A security issue in the JMX Console configuration has been identified that allows an attacker to bypass security authentication.
    The JMX Console configuration only specified an authentication requirement for requests that used the GET and POST HTTP "verbs". An attacker could create a HTTP request that did not specify GET or POST and it would be executed by the default GET handler without authentication. This release contains a JMX Console with an updated configuration that no longer specifies the HTTP verbs. This means that the authentication requirement is applied to all requests.
    For additional information on this vulnerability refer to: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738
    All users are advised to upgrade to this release to resolve this issue.
    If an immediate upgrade is not possible or the server deployment has been customized then the fix can be applied by editing the deployment descriptor (WEB-INF/web.xml) of the JMX Console WAR. Details of how to apply this fix can be found at http://kbase.redhat.com/faq/docs/DOC-30741. Contact Red Hat JBoss Support for advice before making these changes.
    Red Hat would like to thank Stefano di Paola and Giorgio Fedon of Minded Security for responsibly reporting the CVE-2010-0738 issue.
  • CVE-2009-3555: A vulnerability in the TLS protocol allowed an attacker to inject arbitrary requests into a TLS stream during renegotiation. The JBoss Web blocking IO (BIO) connector uses the JSSE implementation of TLS provided by the JVM; therefore, the BIO connector is vulnerable because the JSSE version used is vulnerable. Until a fix is available in JSSE, a new connector attribute, allowUnsafeLegacyRenegotiation has been added to the BIO connector to work around this issue. It should be set to false (the default) to protect against this vulnerability. Users should be aware that the impact of disabling renegotiation will vary with both application and client. In some circumstances disabling renegotiation may result in some clients being unable to access the application.
  • JBPAPP-3079: Session expiration did not trigger flushing of the JBoss Authentication Cache. The PrincipalSessionAttributeFilter has been created in order to place the principal as an attribute of the HTTP session. This attribute is checked when the session expires and, if found, triggers flushing of the authenticated cache. You must uncolmment this filter in Tomcat's web.xml to use this feature.
  • JBPAPP-2873: Twiddle logged all command line arguments, including the JMX password, to twiddle.log. This log file is publicly readable and is created in the current directory. The password argument is now masked in the log file.

JBoss Application Server

  • JBPAPP-3430: Undefined behavior occurred on remote clients that used NestedTransaction when nested transactions were disabled in jbossjta-properties.xml. No nested transaction checking was performed, despite this being unsupported. This update adds a NotSupportedException to be thrown when clients attempt to start a nested transaction.
  • JBPAPP-3328: Farming's AddContentStreamAction attempted to close this InputStream as part of cleanup processing, even though it was not responsible for opening the stream. This caused failures in ClusteredDeploymentRepoAddContentTestCase, which is responsible for the stream. AddContentStreamAction no longer attempts to close the input stream.
  • JBPAPP-3326: ClusteredDeploymentRepository failed when an exploded deployment was removed because the logic that iterated over the contents of the deployment removed items incorrectly. This meant that when an exploded deployment was placed in the farm directory and later removed, a ConcurrentModificationException occurred and ClusteredDeploymentRepository failed. Items are now removed correctly via iterator.remove().
  • JBPAPP-3234: Setting HDScanner's scanEnabled attribute to true via XML would not disable scanning if set to false, and caused a NullPointerException if set to true. Both issues have been resolved.
  • JBPAPP-3213: Deploying EJB3 methods with zero parameters led to NullPointerExceptions. This fix ensures that the deployment will not fail on these grounds.
  • JBPAPP-3180: Hibernate integration code for unsupported second-level caches and connection pools were not included in JBoss Enterprise Application Platform 5.0. The following JARs have been included in common/lib to provide integration for this module:
    • hibernate-ehcache.jar
    • hibernate-oscache.jar
    • hibernate-swarmcache.jar
    • hibernate-c3p0.jar
    • hibernate-proxool.jar
  • JBPAPP-3029: The jboss_init_redhat.sh script is used to start and stop a server instance under a given user name. When using a non-loopback bind address, calling jboss_init_redhat.sh stop resulted in a CommunicationException because of a missing hostname parameter for the remote server the script attempts to contact.
  • JBPAPP-2866: The JGroups protocol stack included an incorrect diagnostic address, 224.0.0.75. The address has been corrected to 224.0.75.75.
  • JBPAPP-2818: The main/src/bin/run.sh did not allow users to override $JBOSS_HOME/bin/run.conf with a profile-specific $JBOSS_HOME/server/$PROFILE/run.conf. This update allows the use of a custom run.conf, if specified.

JBoss Web

  • JBPAPP-3220: When cookies were disabled for the current context, a session cookie from the parent context overwrote the session ID encoded in a URL. The fix for this issue specifies that when cookies are disabled for the current context, the parent context's session cookie should not be sought, and prevents the session ID in the URL from being overwritten.
  • JBPAPP-2929: With buddy replication, when multiple concurrent requests are made with the same session ID after failover, the requests may abort with an org.jboss.cache.lock.UpgradeException while attempting to migrate the cache data to the local node. This no longer occurs, and multiple concurrent web requests made after failover with buddy replication enabled now works correctly.

JBoss Seam

  • JBPAPP-3954: When a Seam ManagedDrivenBean component calls a stateless session bean component in a Seam-managed persistence context, an IllegalStateException ("No event context active") may occur. The component now checks if ContextEvent is active.
  • JBPAPP-3541: Seam could not be compiled from source because its root.pom.xml referenced an incorrect version of javax.transaction:jta:jar. The JAR referenced has been corrected to the correct version javax.transaction:jta 1.1.
  • JBPAPP-3380: jboss-seam-resteasy.jar was not included in the Seam distribution in JBoss Enterprise Application Platform 5.0. This JAR, and relevant documentation, have been added.
  • JBPAPP-3334: The base variable in org.jboss.seam.bpm.JbpmELResolver was passed into resolveVariable instead of the property variable. This meant that the method returned null where it should have returned the task instance. property is now passed correctly.
  • JBPAPP-3292: com.sun.faces.config.ConfigureListener was missing from web.xml. This meant that JavaServer Faces was not initialized when Seam bootstrapped its application scope components, so the JavaServer Faces application context was not available. This class has been added to web.xml and JavaServer Faces now initializes correctly.
  • JBPAPP-3048: The Seam booking example and its derivatives contained outdated page footers. These have been updated for Seam 2.2.
  • JBPAPP-3001: Bash script seam/seam.sh has executable permission only on some Linux systems. This is caused by a different zip util implementation included in the distribution. This has been fixed on Fedora 12 and Red Hat Enterprise Linux 4 and executable permissions are now assigned to seam/seam.sh correctly. The fix is not available for the zip util used on other operating systems such as Ubuntu.
  • JBPAPP-2733: When the Seam examples were tested with the TestNG plugin in JBDS, a java.lang.AssertionError was thrown. To avoid this error it is important to test the examples according to the following instructions:
    1. From the example's home directory (e.g. booking for the booking example), run ant test.
    2. In Eclipse, click on File > New > Project....
    3. Select Java Project from Existing Ant Buildfile from the New Project Wizard, and click Next.
    4. Select the example's build.xml file as the base for the new Java project.
    5. Select Testing Suite or Testing Class.
    6. From the Run As menu, choose TestNG Test. You can cancel the processing of the test run at any time.
    7. Go to Run > Run configurations and edit the created TestNG runner.
    8. If JDK 1.6 is used as runtime, add the following JVM argument on the Arguments tab:
      -Dsun.lang.ClassLoader.allowArraySyntax=true
    9. Go to the Classpath tab and remove all User entries.

JBoss Hibernate

  • JBPAPP-3384: Hibernate collection mapping encountered exceptions if @MapKey was used without an explicit @Type annotation. Without an explicit @Type annotation, Hibernate assumed that the property key type was Serializable and attempted to deserialize an object stream from the database column value. With this update, if @MapKey is not given an explicit @Type, Hibernate uses the original property type instead of the serializable type.
  • JBPAPP-3371: The round function is meant to return values of the same type as the first argument provided (integer, double, or decimal). Previously, it rounded all values regardless of type. All values should now return as the correct type.
  • JBPAPP-3191: The hibernate-ehcache.jar was missing from JBoss Enterprise Application Platform 5.0. This meant that applications that used ehcache as the Hibernate second-level cache provider failed with a NoClassFoundException. A signed version of hibernate-ehcache.jar is available from CSP: https://support.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=1037. This JAR should be placed into the following directories:
    • $JBOSS_HOME/server/all/lib
    • $JBOSS_HOME/server/production/lib
    • $JBOSS_HOME/server/web/lib
  • JBPAPP-3173: Using Javassist as the bytecode provider to instrument your domain model caused errors if an entity extended a parent class with an abstract method. Hibernate code used return instead of continue in a while statement, which caused the statement to skip all other attributes that should have been used. This has been corrected.
  • JBPAPP-3115: The Hibernate Javadoc referenced the wrong version of the JDK objects. These references have been updated to http://java.sun.com/j2se/1.5.0/docs/api/.
  • JBPAPP-3098: When a filter with a collection type parameter was used, and the number of parameters in that collection changed during the lifetime of the SessionFactory, the SQL would not be updated to reflect the change in the number of parameters. This typically resulted in the following error:
    java.sql.SQLException: Parameter index out of bounds.
      2 is not between valid values of 1 and 1
    This occurred only with HQL, not Criteria, and has now been corrected.
  • JBPAPP-3089: A long IN list could result in stack overflow during parsing. A query element like where x in (:x) or a manually-constructed where x in (1,2,3,...) could generate a stack overflow if the number of elements referenced by x exceeded a number dependent on available stack space. For Java Virtual Machines, the limit is between 9000 and 10000, assuming a relatively empty stack at the point of query execution.
    The stack overflow occurred in org.hibernate.hql.ast.util.NodeTraverser because it used a recursive algorithm to walk a parse tree. A long IN list generated a very deep sub-tree, so a sufficiently long list caused the stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times. This recursive algorithm has been replaced with an iterative tree-walking implementation to fix this issue.
  • JBPAPP-2957: The evictAll() method in EntityRegionAccessStrategy and CollectionRegionAccessStrategy should remove objects from the cache immediately, without regard for transaction isolation. The Hibernate/JBoss Cache integration did not handle this correctly, as the JBoss Cache removeNode calls it made did not deal with transactional issues. This usually results in a IllegalStateException or a JBoss Cache CacheException when a transaction that had made a bulk update was committed, or when using the Hibernate SessionFactory evict methods.
    To fix this issue, any ongoing transaction in evictAll() will now be suspended before invoking JBoss Cache's removeNode. To cater for transactional issues, state is now stored in the integration layer's Region to track where eviction has occurred but may not yet be reflected in JBoss Cache. JBoss Cache is used as a notification bus to propagate the eviction to other nodes. Eviction occurs locally, and fails immediately where lock conflicts occur. State is also checked in the get() and putFromLoad() methods.
  • JBPAPP-2922: Hibernate warns that the cglib BytecodeProvider impl is considered deprecated and is not recommended for use. cglib is not deprecated, so this warning can be safely ignored.
  • JBPAPP-2900: MySQL uses the TEMPORARY keyword to bypass implicit transaction commits. Previously, Hibernate used <CREATE TEMPORARY TABLE> with <DROP TABLE>. Omitting the TEMPORARY keyword caused an implicit commit, and immediate failure within an XA Transaction. <DROP TEMPORARY TABLE> is now supported and this issue no longer presents.
  • JBPAPP-2892: When Enterprise JavaBean 3.0 entities were used with optimistic caching, org.jboss.ejb3.entity.OptimisticJBCCache.DataVersionAdapter.newerThan incorrectly returned true for A.newerThan ( A ). This caused a DataVersioningException when JBoss Cache attempted to remove the entry. The method has been corrected so that it returns false. Note that the recommended approach is to use Multiversion Concurrency Control (mvcc-entity) instead of optimistic caching.
  • JBPAPP-2858: Native queries were automatically paginated in getSingleResult(), which caused getSingleResult() to fail for some databases and queries. This behaviour has been changed so that Hibernate no longer alters setMaxResult for native queries in getSingleResult().
  • JBPAPP-2277: Hibernate uses ClassLoader.loadClass() was used in SerializationHelper$CustomObjectInputStream, but is no longer supported by default as of JDK 6 (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 for further information). Attempting to load an array using this method resulted in a ClassNotFoundException. SerializationHelper$CustomObjectInputStream now uses Class.forName(className,false,myClassLoader) to resolve classes.
  • JBPAPP-2082: Associations marked as mappedBy must not define database mappings like @JoinTable or @JoinColumn. This fix adds an AnnotationsException, which is thrown when Hibernate receives this invalid mapping.
  • JBPAPP-1998: EntityNotFoundException is incorrectly thrown upon an optimistic locking failure when one EntityManager tries to delete an entity that has been updated by a different EntityManager and hibernate.jdbc.batch_versioned_data is set to false (the default value). OptimisticLockException is now thrown instead.
  • JBPAPP-1547: org.hibernate.dialect.SybaseASE15Dialect.areStringComparisonsCaseInsensitive() now returns true. This was done because, by default, Sybase ASE 15 string comparisons are case-insensitive. Since Sybase can be configured to be either case-sensitive or case-insensitive, if the Sybase database is configured for case-sensitive comparisions, the previous setting (false) was incorrect.

Documentation

  • JBPAPP-3380: RESTEasy integration information has been added to the Seam Reference Guide.
  • JBPAPP-3863: The Administration and Configuration Guide indicated that the JDBC blocking-timeout-millis property's default value is 5000 milliseconds. This incorrect value has been replaced with the true default value, 30000 milliseconds.
  • JBPAPP-2948: The deploy/jmx-remoting.sar service instantiates a JSR-160 adapter for standardized remote access to the JBoss MBeanServer. This service is used with tools such as the JConsole. At present, this service does not support secure access. In production environments where the server binds to a specific address other than localhost this presents a potential security risk, so the adapter has been moved from the deploy directory into docs/examples/jmx. We do not recommend enabling it for production usage. If during development you wish to re-enable the adapter, copy it back to the deploy directory.
    The adapter has been moved to /docs/examples. If you wish to re-enable it, move it back to the deploy directory.
  • JBPAPP-2802: The JBoss Cache documentation did not indicate that Non-Blocking State Transfer was unsupported. Unsupported information about Non-Blocking State Transfer has now been removed from the JBoss Cache documentation associated with JBoss Enterprise Application Platform.