Consoles

JBPAPP-6889

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

Documentation

JBPAPP-6214

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

HornetQ

JBPAPP-5760

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

Installer

JBPAPP-6680

Splash screens can now be used via izpack. The following tag must be provided via the resources.xml inside the <xfragment> tag : <res id="splash" src="@{install.config.dir}/images/splash.png" />. The src is user configurable however the id must remain "splash". The splash size is directly proportional to the size of the image provided.

JBPAPP-6514

The installer has been improved so that at the end of a GUI installation you can save to a file the options chosen, then use this as input to the installer to re-create the exact installation. This option can be useful when you need to deploy the same EAP installation to multiple servers: e.g. cluster nodes, bulk deployment of new EAP servers. To use this feature:

1. Complete the installation;
2. At the final panel, click on "Generate an automatic installation script" and save the file;
3. Use the installation script as follows: java -jar <path to jar> <path to generated file>, e.g. java -jar /home/tester/enterprise-installer.jar /home/tester/generatedfile

Seam2

JBPAPP-6498

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

Security

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

System

JBPAPP-6716

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

Apache Server and Connectors

JBPAPP-5585

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

Clustering

JBPAPP-6175

During distribution of the encryption key from the master node to each cluster member, the configured asym_provider and sym_provider were not used. These options are now set to be used when getting Ciphers.

JBPAPP-6408

In some circumstances, HA-JNDI could start processing requests before it was fully initialized, causing those requests to fail with a NullPointerException. This has now been resolved so that initialization is confirmed before processing begins.

JBPAPP-6797

The deployment of a HASingletonController as an MBean could fail if the MBean upon which it depended had not yet been started. To fix this issue the availability of dependent MBeans is first checked before deployment, resulting in reliable deployments of HASingletonController.

JBPAPP-6899

If there were concurrent calls to the UnifiedInvokerHAProxy function a NullPointerException error could occur when the last server was shut down. The issue was that the logic surrounding this function did not check if a target was available, resulting in the following error:

FATAL [org.jboss.invocation.unified.interfaces.UnifiedInvokerHAProxy] (TP-Processor242) Could not initialize UnifiedInvokerProxy.

The logic surrounding the proxy function has been changed so it first checks the availability of a target, preventing NPE errors.

JBPAPP-6989

When using the legacy eviction policy configuration format, if the wakeUpIntervalSeconds was not specified, the default value was set to 5000 seconds, not 5 seconds. This resulted is wakeUp intervals far longer than would be expected. This has now been resolved and the default is 5 seconds.

JBPAPP-6538

When creating a cache using the CacheJmxWrapper the ClusterConfig section was ignored, and a default JGroups configuration used. The cause of the problem was that the parser was ignoring the contents of the <ClusterConfig> section. This problem has been fixed and the whole of the cluster configuration file is read correctly.

JBPAPP-7015

Transaction stickiness has been enabled by default for EJB3 load balancing policies. This means that there's no need to create and configure separate load balancing policies to enable this feature.

JBPAPP-6869

It was not possible to specify default loadBalancePolicy for Clustered EJB3s because the EJBs already had @Clustered on them. This has been corrected and you can now edit $JBOSS_HOME/server/all/deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml and add properties such as RoundRobin, or specify fully qualified class names such as org.jboss.ha.client.loadbalance.RoundRobin The default for defaultLoadBalancePolicy is org.jboss.ha.client.loadbalance.RoundRobin if not specified. The default for defaultStickyLoadBalancePolicy is org.jboss.ha.client.loadbalance.FirstAvailable if not specified.

JBPAPP-6972

Fix an EJB3 clustered proxy bug where the clustered proxy factory implementation(s) do not take into account the overridden stackname and instead uses the default clustered client interceptor stack. This means that the @RemoteBinding(interceptorStack=...) annotations and the <interceptor-stack> tags in the jboss.xml file is ignored for clustered EJBs.

JBPAPP-6448

Deploying Web Applications (WARs) to a cluster farm via either the EAP Administration Console or JBoss Operations Network caused a NullPointerException on the joining node, similar to the following:

16:16:53,586 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey@27905a42[domain=default, server=default, name=farm] state=Configured mode=On Demand requiredState=Installed
java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:796)
at org.jboss.ha.timestamp.TimestampDiscrepancyService.getTimestampDiscrepancy(TimestampDiscrepancyService.java:328)
at org.jboss.profileservice.cluster.repository.DefaultSynchronizationPolicy.getTimestampDiscrepancy(DefaultSynchronizationPolicy.java:158)
at org.jboss.profileservice.cluster.repository.DefaultSynchronizationPo
licy.acceptUpdate(DefaultSynchronizationPolicy.java:121)

The cause of the error was incomplete internal data when checking time synchronisation between the deployer and deployee cluster nodes. This issue has now been fixed and deployment of WARs to cluster nodes is successful.

JBPAPP-6932

When two cluster nodes were merged after a split, only one of them should have continued to HASingletons. In fact both continued to run HASingletons, resulting in unreliable cluster operation. The cause was an error in the logic applied when node merged. This is now resolved and cluster merges now operate as expected.

JBPAPP-7011

Data loss could occur when calling cache.getNode in JBoss Cache with a cache loader configured for passivation. When cache.getNode loaded a passivated node, the data was not loaded, but it did trigger an eviction event. When eviction then passivated the node again, the data was overwritten. This issue has now been resolved and data loss no longer occurs in these circumstances.

Consoles

JBPAPP-6683

Directly accessing pages of the JBoss Web Console resulted in an exception error. This has been fixed by ensuring that access to the web console is only available via its start page.

JBPAPP-6682

An exception occurred when creating a new Threshold Monitor via the JBoss Web Console. This has been fixed by checking that the DeploymentFileRepository MBean is available and if not, showing an error message.

Documentation

JBPAPP-7236

The Standard Server Profiles section of the Administration and Configuration Guide stated incorrectly that the "All" profile is used if no profile is explicitly stated or configured. In fact the profile named "Default" is used in these circumstances. A new section Run the Application Server as a Service on Red Hat Enterprise Linux has also been added to the Installation Guide.

JBPAPP-7361

The "Workaround for Oracle" section of the Administration and Configuration Guide has been updated with the latest available information. If you are using Oracle, please check this section to see if it's relevant to your installation.

JBPAPP-4828

Instructions on upgrading EAP from 5.1.1 to 5.1.2 and later have been added to the Installation Guide.

JBPAPP-4958

In the Hibernate Core User Guide, a reference was made to an incorrect POM file. This reference has been updated in the documentation for the current release.

JBPAPP-5566

A bug in class org.jboss.mail.SessionObjectFactory caused only one mail service to ever be resolved, even if more than one service was configured and present in the JNDI tree. The class now resolves more than one mail service if one is configured.

JBPAPP-6138

A new section has been added to the HornetQ User Guide in the "Configuring Message-driven Beans" Section. The new section entitled "High Availability in Message-Driven Beans" explains the need for the "cluster" activation property in MDBs used in Clustered environments.

JBPAPP-6213

A node fails to read all its messages if disconnected from its database. This happens because the node fails to acknowledge messages on database disconnection. To avoid the problem, set the node parameter MaxRetry to a value greater than -1. You can set the attribute value in the MBeans PersistenceManager, PostOffice, and JMSUserManager in the file [database]-persistence-service.xml. The Messaging User Guide now contains details about the MaxRetry parameter, and how to configure it in conjunction with other related parameters.

JBPAPP-6741

The Administration and Configuration Guide has two new chapters: Enterprise Applications with EJB3 Services and Legacy EJB Support.

JBPAPP-6887

In the Using the Security Manager section of the Security Guide, the instructions for importing JBoss signing key were incorrect. The path to the keytool utility was listed as $JBOSS_HOME/bin/keytool but it should have been JAVA_HOME/bin/keytool. This section of the Guide has now been corrected.

JBPAPP-6958

Fencing for GFS2/SAN was not discussed anywhere in the HornetQ User Guide. While Fencing is required by HornetQ, the variety of ways to enable Fencing precludes specific discussion in the User Guide. To fix the issue, a new "Fencing" section was added to the "High Availability and Fail-over" Chapter. The section describes how to locate more information about configuring Fencing in other Red Hat documentation.

JBPAPP-7000

The HornetQ User Guide contained incorrect information on clients running inside a Java 5 Virtual Machine and referred to jars, which are no longer delivered in the Client Classpath chapter. The chapter now provides accurate information on these issues.

JBPAPP-7200

The Administration and Configuration Guide did not specify the ServerPeerID range (between 0 and 1023) required for JBoss Messaging in the Clustering Section of the guide. This caused problems with users specifying values outside of these ranges, which resulted in a java.lang.IllegalArgumentException. The fix adds an admonition to the "Initial Preparation" section detailing the node range required. Customer now know the range available when setting node ServerPeer IDs.

JBPAPP-7324

It was discovered that Windows customers were encountering problems when installing the platform using the Graphical Installer. Not correctly setting the JAVA_HOME environment variable before running the installer caused an warning message to display. The Installation Guide has been updated with a Task prerequisite of setting JAVA_HOME, with links to the appendix containing these instructions.

EJB

JBPAPP-4656

In the event of a transaction rollback during a timeout callback, the timeout callback must be retrieved as per spec EJB 3.1 FR 18.4.3. The container did not enlist the timer into the transaction and the timer could not be retrieved on rollback. Timer callback implementation has been changed to support running within transactions so that after the timeout callback is rolled back, the callback is retired by the service.

JBPAPP-5516

When messages were sent to a MDB which was not fully prepared to receive them, the MDB container would throw a DispatcherConnectException. Because this was a checked exception, and therefore ignored for determining transaction semantics, the transaction would commit and the messages would be acked without the MDB ever seeing the messages. The fix introduces new logic which checks that any exception is properly checked against the signature of the inflow method. Any invalid exception results in an UndeclaredThrowableException (/RuntimeException). When a RuntimeException is encountered during message inflow, the transaction is rolled back. Messages within that transaction are not acknowledged and retried at a later interval. The assumption is that the MDB is ready by that time to receive messages normally and thus normal operation resumes.

JBPAPP-6953

If an EJB jar deployment specifies a dependency and this dependency is restarted, the deployment or start of the EJB would fail with an IllegalStateException message similar to the following:

Caused by: java.lang.IllegalStateException: jboss.j2ee:ear=helloWorld.ear,jar=helloWorld-ejb.jar,name=HelloBean,service=EJB3 is already installed.

This was caused because the EJB's deployment was duplicated during the installation or start. To resolve this problem before upgrading to EAP 5.1.2, either redeploy the dependent EJB or restart the server. This problem has been fixed and this workaround is not required once you have upgraded.

JBPAPP-6789

A clustered EJB using @RemoteBinding(jndiBinding=...) or <remote-binding> incorrectly created a proxy in JNDI, then replaced it with the correct proxy. When the cluster membership changed, the wrong proxy's cluster member list was updated, so the EJB clients were not informed about the new member. The extra proxy is no longer created and removed. The cluster member list now updates correctly, allowing EJB calls to load balance and failover to the new nodes.

Embedded Jopr

JBPAPP-6765

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

HornetQ

JBPAPP-6303

When a HornetQ queue was hosted on a remote HornetQ broker, and was not defined on the local instance of the HornetQ broker, HornetQ activation was ignoring multiple forward-slash characters in JNDI queue paths. If a queue was specified as <queue name="jms/queue/myQueue">, HornetQ was interpreting this as <queue name="myQueue">. An MDB listening on a remote queue was unable to connect to the queue because the forward-slashes were removed from the queue name. This issue is now fixed as part of this release.

JBPAPP-7205

In a situation with clustered HornetQ instances where a cluster node has its journal disconnected - e.g. when the server loses its connection to the SAN - the other nodes did not take over in place of the failed node. This problem has now been fixed and failover from a failed HornetQ node now occurs without interruption to the client.

JBPAPP-7556

The default delay for message redelivery has been changed so that it's now 60000 milliseconds, or 1 minute. The default value was previously 0, which meant no redelivery delay. The specific change has been made in hornetq-configuration.xml.

JBPAPP-5895

An issue was discovered in a clustered HornetQ configuration where a client failed to connect (using JNDI) to the backup instance when the active node failed. The underlying cause of this issue was identified and fixed so that the client can now fail over from the active node to a backup node.

JBPAPP-7455

An issue was identified with cluster connections in that the core bridge service was ignoring the min-large-message-size specified in the configuration, instead using the default value of 100 KiB. This has been resolved and the min-large-message-size value is now recognized if specified in the configuration.

JBPAPP-5080

On server shutdown, HornetQXAResourceWrapper logs a warning on connection failure. This happens because the life-cycle of HornetQXAResourceWrapper is controlled by the Transaction Manager. The fix adds a recovery API to HornetQ, which fixes the issue.

JBPAPP-6368

HornetQ did not ship with a switch.bat script for customers running HornetQ on Microsoft Windows servers. While HornetQ could be installed by running ant in the HornetQ directory containing the build.xml file, this was not consistent with the Linux environment. A switch.bat script is shipped for Microsoft Windows customers, which replicates the switch.sh script behavior in Linux environments.

JBPAPP-6522

It was discovered that the HornetQ core bridge service was hanging if the target server was terminated while large *bytemessages* of approximately 270MB were being delivered. The contents of the failed messages were not cleaned up from the target server's data/large-messages directory.

When the server was terminated more than once during large *bytemessage* transmission, multiple files would persist in thedata/large-messages directory. The only way to correct this issue was to restart the server that the bridge service was deployed on.

The fix implements changes to the core bridge, which now restarts until it successfully reconnects to the target server. The bridge no longer hangs when the target server is terminated, which corrects the issue.

JBPAPP-7115

In a clustered HornetQ configuration, messages 1 MB or larger in size could get stuck in the queue, resulting in a NullPointerException. This has been solved with large messages now catered for in a clustered configuration.

JBPAPP-7161

If the server crashed while transmitting a large message, the message remained in the large message directory unless removed manually. A temporary record is now added on the journal marking of the file and the file is deleted if corrupted.

IIOP

JBPAPP-6469

IIOP deployments were not being deployed when using the standard profile because the file ejb3-iiop-deployers-jboss-beans.xml was not in $JBOSS_HOME/server/standard/deployers/ejb3.deployer/META-INF. This file is now present, and IIOP deployments now work in the standard profile.

JBPAPP-6956

A new CORBA naming context implementation has been added which uses a local cache to resolve names and avoid unnecessary remote calls.

JBPAPP-6462

Use of a custom CORBA servant inside an isolated EAR would cause ClassNotFoundExceptions if the servant tried to call an in-EAR EJB due to the use of an incorrect thread context classloader (TCCL) by JacORB. The cause of this problem has been fixed by ensuring that the TCCL of the servant class is used instead.

Installer

JBPAPP-6954

The installer had a Previous button available but if it was pressed, already installed files would be left installed. To prevent this occurring the Previous button is now disabled.

JBPAPP-7540

On Red Hat Enterprise Linux, menu items created by the installer were not available to all users, despite the checkbox "Create shortcuts for all users" being checked. The cause was inverted logic in the installer, so that the menu items created were available to all users only if the "Create shortcuts for all users" was not checked. This problem has now been fixed.

JBPAPP-7565

Menu items created by the installer on Microsoft Windows were not consistent with those created on Red Hat Enterprise Linux. The cause of the problem was that the run commands used in some of the menu items was invalid on Windows. The installer has been fixed so that all menu items are now valid on both operating systems.

JBPAPP-7568

Shortcuts created by the installer on Microsoft Windows had an incorrect path specified, which resulted in the shortcuts failing to start the platform. The path given included "jboss-as" but this should have been "jboss-as-web". The installer has now been corrected so that the shortcuts included the correct path.

JBPAPP-7566

On Windows, shortcuts which contained Asian characters were not removed by the uninstaller. The cause of the problem was found to be incorrect string encoding. This problem has since been fixed and all shortcuts created by the installer are successfully removed when the uninstaller is used.

JBPAPP-6376

The DVD Store demonstration Seam application provide with the Enterprise Application Platform failed to deploy. The application is now updated and will successfully deploy.

JBPAPP-6603

When running the installer with OpenJDK the buttons along the bottom of the window were cut off, making accessibility an issue. This has been resolved by changing their orientation slightly.

JBPAPP-6405

On Windows with either Japanese or Chinese localization settings, the Enterprise Application Platform's installer failed to create shortcuts in the Start menu and the users' desktop, requiring the user to manually start the application via either Windows Explorer or a Command Prompt. This problem has been fixed and the in these circumstances the installer now correctly creates shortcuts in both locations.

JCA

JBPAPP-6939

The JCA DTD (jboss-ds_5_1.dtd) referenced an element named "background-validation-minutes" but this was incorrect and should have been "background-validation-millis". This has now been corrected and the DTD now contains the element's correct name.

JBPAPP-7102

Datasources exposed remotely via RMI used the maps of connections and statements in a way that was not threadsafe. This resulted in either clients receiving an error message "unable to find statement" or the server getting stuck in an infinite loop due to the map data structure being corrupted. This issue has been resolved by changing the method of access to the remote datasource's map, so that it is thread-safe.

JBPAPP-6855

When recommended properties in an activation specification were not available, a DeploymentException error such as the following would occur:

08:20:50,262 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:binding=message-driven-bean,jndiName=local/gss_mdb_20@32140521,plugin=invoker,service=EJB state=Create mode=Manual requiredState=Installed
org.jboss.deployment.DeploymentException: Unable to create activation spec ra=jboss.jca:service=RARDeployment,name='wmq.jmsra.rar' 
...

The validation of properties has been changed and the following warning message is now output if an unknown or unsupported configuration property is detected:

17:52:45,801 WARN  [ActivationSpecFactory] Unable to set 'foo' property on org.jboss.resource.adapter.jms.inflow.JmsActivationSpec

JBPAPP-6684

A deadlock could occur when multiple threads accessed the JCA layer to either commit or roll back a transaction. The JCA code has been updated to resolve these problems and multi-threaded access should now work correctly.

JBPAPP-6943

The configuration settings allocation-retry and allocation-retry-wait-millis and no-tx-separate-pools did not work if they were specified in the configuration file (*-ds.xml) but did work if changed via the JMX Console. The cause of this problem has been resolved so these settings can now be configured via either method.

JMX

JBPAPP-6900

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

Messaging

JBPAPP-5280

The MessageSucker is responsible for migrating messages between different members of a cluster. The onMessage routine attempts to deliver messages to the local queue, among other tasks. If delivery failed, messages appeared to be lost. They were still in the database, but it was difficult to redeliver them. This was a defect in the JBoss Messaging component, and has been fixed in that component. The fix is complex, and is discussed in JBMESSAGING-1822, which is available at https://issues.jboss.org/browse/JBMESSAGING-1822. In short, a new layer of reliability has been added to the message delivery logic.

JBPAPP-6620

The messaging server would not start in default profile when configured to use a database other than HSQLDB database. This was caused by not commenting out lines in the database_type-persistence-service.xml file that were applicable only to clustered profiles.

The fix adds prescriptive comments to the database_type-persistence-service.xml file, instructing how to comment out unnecessary configuration directives for non-clustered messaging server instances.

Naming

JBPAPP-6431

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

Other

JBPAPP-5148

Deployment file names were not previously checked for legal paths. Poorly-constructed file names could cause unexpected file deletions or alterations. The deployment files are now checked for legal paths, and an exception is thrown if an illegal path is used.

JBPAPP-6046

If the Simple Logging Facade for Java or (SLF4J) was used in a top-level classloader such as the endorsed classpath, it would cause NullPointerExceptions. The cause of this problem has been resolved and SLF4J can now be used in a top-level classloader.

JBPAPP-6486

JAXB elements were not processed correctly when preceded by elements with xsi:nil=true. This issue has now been resolved and JAXB elements are processed correctly.

JBPAPP-6524

Configuration of "use_tccl=false|true" could be unreliable if there were several commons-logging.properties files. To fix this problem a new system property org.apache.commons.logging.use_tccl has been created, with the default still being true.

JBPAPP-6824

A deployment configured with parent-first=true is not delegating to the parent when loading resources (getResource). To enable this functionality set

-Dorg.jboss.classloader.honor.resource.delegation=true

and resources will be loaded parent-first if so configured. This can be done on the run.sh command or in the $JBOSS_HOME/bin/run.conf in JAVA_OPTS environment variable.

JBPAPP-6849

The "Migrating to HornetQ" section did not contain specific information about migrating JBoss Messaging applications where High Availability was concerned. A new section "Client-side Failure Handling" is now available in the guide, which details the extra code required to correctly handle HornetQ failover exceptions.

JBPAPP-6884

The XML Schema Declaration "jboss-xa-ds.xml" has been removed. All data source deployments in EAP 5.1.x should use the jboss-ds_5_1.dtd instead.

JBPAPP-7128

The getModulePath method of SimpleJavaEEModuleInformer did not follow the JavaEEModuleInformer specification as the getModulePath method returned an empty string for a top-level non-ear deployment. The method now returns the module name for such deployments and therefore meets the JavaEEModuleInformer specification.

JBPAPP-7241

In rare circumstances, a PagedReference could be garbage collected before messages were consumed, resulting in pagecredits getting out of sequence and the affected messages being stuck. A minimal page-size is one factor in the circumstances leading to this problem. This problem has now been solved by detecting and better handling these circumstances.

JBPAPP-7093

In an earlier release the caching behaviour in XMLReaderManager was removed to resolve a memory leak. This forced each invocation to recreate the XMLReader and, as a result of the presence of the Synchronized methods, contend with other threads. Caching has been reinstated through the use of the SAXParser class, resolving the issue of thread contention. The original issue of a memory leak is avoided by use of the SAXParser reset method.

Scripts and Commands

JBPAPP-5901

On RHEL 6 the JBoss service script had some backslashes incorrectly escaped, resulting in an invalid command and stopping JBoss being started or stopped. The script has been fixed and JBoss can reliably be started and stopped on RHEL 6.

JBPAPP-6944

On a "service stop" request on Red Hat Enterprise Linux the JBoss Enterprise Application Server service could fail to shutdown with a timeout failed error. The init script was modified to make sure the service shuts down correctly on service stop request.

JBPAPP-6951

When the log $JBOSS_HOME/server/$JBOSSCONF/log/server.log contained more than one instance of a server start-stop sequence, the shutdown script mistakenly detected that the server had shut down before it had actually been shut down properly. This problem has been fixed by changing the the script to monitor the server's process ID (PID) instead of the log file.

JBPAPP-7013

All *.xml and *.property files have been changed to Windows-compatible format (line endings). To change them to UNIX-compatible format, run the script jboss-eap-5.1/jboss-as/bin/convert-dos2unix.sh, ensuring that you run it in the jboss-eap-5.1/jboss-as/bin/ directory.

Seam

JBPAPP-5039

An incompatibility with Microsoft Internet Explorer 8 and the Seam Tasks Example resulted in text appended to a task being represented as a blank line in the task list. The Seam Tasks Example was improved to display edited tasks correctly in Microsoft Internet Explorer 8.

JBPAPP-6611

An EAR project generated using seam-gen from EAP 5.1.1 contains some wrong dependencies in .classpath file: core.jar and janino.jar. These are no longer required and have been removed from Eclipse's classpath file and should be removed from any existing EAR project if you updated Seam and Drools jars from EAP 5.1.2 release in your existing EAR application.

JBPAPP-6650

When mail messages were created using the Seam Mail tag <ui:repeat...>, the list of attachments was cached and so each recipient received the attachment multiple times. This has been fixed by resetting the attachments list after it has been added to the message's body.

JBPAPP-6751

The ServerConversationContext.flush() method created in some cases PersistentContext and BusinessContext instances and these instances lived in memory until the HTTP Session was invalidated. This problem is solved by creating them only when required.

JBPAPP-6946

A multipart request was not parsed correctly if CRLF+CRLF (Carriage Return Line Feed) in the header line was separated at the buffer boundary; that is, the header buffer ended with CRLF and the following byte was CRLF. This caused a MultipartRequest error and excessive CPU memory usage. Such multipart request is now parsed correctly and the error no longer occurs.

JBPAPP-7084

The org.apache.el.util.concurrentcache class did not synchronize requests for concurrent access to WeakHashMap. In some cases, this caused an infinite loop, which consumed excessive CPU memory. The underlying issue has now been resolved and access to WeakHashMap in the org.jboss.el.util.concurrentcache class is now synchronized.

JBPAPP-7139

It was found that the Attribute Exchange (AX) extension of OpenID4Java was not checking to ensure attributes were signed. If AX was being used to receive information that an application only trusts the identity provider to assert, a remote attacker could use this flaw to conduct man-in-the-middle attacks and compromise the integrity of the information via a specially-crafted request. By default, only the JBoss Seam openid example application uses OpenID4Java. (CVE-2011-4314).

• openid4jav-nodeps.jar
• httpclient.jar
• httpcore.jar
• nekohtml.jar
• jcip-annotations.jar
• guice.jar
• commons-codec.jar

Security

JBPAPP-6364

It was found that the invoker servlets, deployed by default via httpha-invoker, only performed access control on the HTTP GET and POST methods, allowing remote attackers to make unauthenticated requests by using different HTTP methods. Due to the second layer of authentication provided by a security interceptor, this issue is not exploitable on default installations unless an administrator has misconfigured the security interceptor or disabled it. (CVE-2011-4085)

JBPAPP-6893

In prior EAP 5 releases, use of cglib.jar would cause security exceptions since code generated by cglib overlapped with the cglib JAR packages that were signed. To resolve this issue cgilib.jar has been unsigned and the security policy has been modified to account for this change.

JBPAPP-6996

Under heavy load a ConcurrentModificationException could occur in the SimpleRoleGroup class, resulting in the user being unauthorized. The cause of this problem has been identified and corrected and no longer occurs.

SNMP

JBPAPP-6504

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

System

JBPAPP-6545

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

Web

JBPAPP-7267

When Jasper was using the ParserUtils of JAXP, the calls between the framework's classes and deployment's classes were blocked because they were deliberately isolated from each other. To avoid this problem these calls have been modified so that they work in an isolated environment.

JBPAPP-6141

Because of an issue in Tomcat, the time offset when Daylight Savings Time came into effect was wrong. This has since been fixed and the offset calculations are now correct.

JBPAPP-7089

If there was a @PostConstruct annotation, or other annotation, on a method which was overloaded by another method with the same name, the call to that method would fail with an exception error. This occurred because no arguments were passed to the method and only the presence or absence of the method was being checked, not the presence or absence of methods. To resolve this issue further checks have been added so that the presence of parameters is confirmed prior to the method being invoked.

JBPAPP-6724

When mixed methods of authentication were used in the one deployment, the WebAuthentication method would prevent the start of a single sign-on (SSO) session. This problem is resolved and WebAuthentication now works correctly with SSO sessions.

JBPAPP-6501

An error occurred when a getter method returned an empty string and numeric conversion was attempted. This has been fixed by testing for and better handling the empty string.

JBPAPP-7104

The injection of @EJB or @Resource fields into superclasses of JSF Managed Bean were failing. When @EJB were to be injected via annotations, those annotations were not being processed, leaving their fields null, or otherwise unset. The cause of this issue has been resolved and these injections now work as expected.

Web Services

JBPAPP-7124

The CXF installer removed the jettison.jar, stax-ex.jar, and streambuffer.jar files from the client/ directory if they were available. However, these files could be used by non-WS clients and some applications could fail to work after CFX upgrade or installation. The installer now no longer removes these files and the applications work as expected even after CXF installation or upgrade.

JBPAPP-6822

An endpoint implementation annotated with @HandlerChain and WS-Security (WSSE) enabled caused a duplicate SOAP body to be appended. The cause of this problem has been resolved and no duplication now occurs.

JBPAPP-6593

In JBoss EAP 5.1.1, running the httpbinding example caused errors. These occurred because JBossWS Native forced JBoss Remoting to close the streams. This enforcing introduced regressions that have been fixed in JBoss EAP 5.1.2.

JBPAPP-6729

Some clients failed to parse web service responses sent from JBoss that were MTOM/XOP encoded because JBoss Web Services failed to add the "charset" parameter to the root MIME part if the used charset was different from the implicit default "ISO-8859-1". The "charset" parameter is now added to the web service response if necessary.

JBPAPP-6734

The system threw a RuntimeException if a policy reference was wrapped in a <wsp:policy> element in a wsdl file. This happened because it failed to resolve the policy reference. The policy reference can now be either wrapped in the <wsp:Policy> element or defined as a standalone element (without being wrapped in the <wsp:Policy> element).

JBPAPP-6371

JBossWS shell script and batch files from the CXF stack (wsconsume, wsprovide, wsrunclient) were inconsistent with their use of the -Djava.net.preferIPv4Stack configuration option. This has been changed and both the Native and CXF stacks are configured with an IPv4 preference.

JBPAPP-6389

The schema validation feature supported one imported schema only. Now, you can define @SchemaValidation on a WSDL that defines multiple schema imports.

JBPAPP-5866

SOAPFactoryImpl forces additional namespace declarations in all child elements that are not immediate child elements of the element declaring the namespaces. This explicit declaration is redundant and is now no longer added.

JBPAPP-6285

JBoss Web Services threw an org.w3c.dom.DOMException when it attempted to create a dispatch client with an EnpointReference. This happened because the server appended a node from another document to the dispatch client in some concurrent environments. JBoss Web Services now appends the correct node to the dispatch client and creates the dispatch client with an EndpointReference correctly.

JBPAPP-6186

The password digest of the UsernameToken profile used in JBoss Web Services did not follow the Oasis specification as the digest used the base64 encoded nonce. As a result, the process was incompatible with other web service implementations that support UsernameToken profile. The password digest has been corrected to use the binary value of the nonce and JBoss Web Services works with other implementations in the UsernameToken profile as expected.

JBPAPP-6245

JBossWS native does not properly protect against recursive entity resolution with embedded DTDs. A remote attacker could cause a Denial-Of-Service by CPU resource exhaustion with a carefully crafted POST request to a deployed web service. (CVE-2011-1483)

JBPAPP-6249

The JBossWS-CXF JAXWS client relies on the CXF ProviderImpl which requires a Bus instance. Unless a Bus was associated with the current thread, the Bus retrieval process returned the Bus instance that was created for the server. Now a customized Provider implementation creates a new Bus instance for the client and the Bus request returns this Bus instance.

JBPAPP-6529

When a CXF endpoint received an HTTP GET request, it threw a NullPointerException at org.apache.cxf.staxutils.StaxUtils.readDocElements. Although a GET request to the endpoint should cause an exception, a NullPointerException is not appropriate. The endpoint now filters the GET requests and safely skips the code that caused the exception.

JBPAPP-6479

If a wsdl part contained a header with partIndex 0, the JAX-WS runtime threw an IllegalArgumentException due to an incorrect number of arguments in the dispatch/provider service. With this update the arguments are checked and added to the argument list as expected.

JBPAPP-6267

When a client sent a message with an MTOM (Message Transmission Optimization Mechanism) attachment, which was larger than 64K to JBoss Web Services, the server deleted the swap file in ServiceEndpointInvoker before the response message processing was completed and returned a FileNotFoundException. Now the swap file is deleted after the response processing has been completed and the error no longer occurs.

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.