Chapter 5. Known Issues

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

Clustering

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

Consoles

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

Documentation

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

EJB

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

Hibernate

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

HornetQ

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

Messaging

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

RESTEasy

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

Seam

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

TCK

JBPAPP-3929
When java.sql.Date.valueOf attempts to parse dates of the format yyyy-mm-dd, the TCK test threw a java.lang.IllegalArgumentException. This was due to a regression in the latest Sun JVM, Sun JDK 1.6.0_24 (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6898593 for more information). The workaround for this issue is to downgrade to Sun JDK 1.6.0_17.

Transaction Manager

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

Web

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