This change is related to BZ-956805.

There's a dependency issue that causes intermittent infinispan startup
failures in EAP6. Part of the related systems have been changed and I
can't find occurances of this issue in upstream or replicate it because
of those changes. However the dependency issue does still technically
exist.
WFLY-1906 AS7-4547 Remove the -XX:+TieredCompilation JVM option from the standalone.bat
WFLY-510 JSR-322 Java EE Connector Architecture 1.7
WFLY-510 Applying changes suggested in PR review. Squash it before merge
WFLY-1896 - CLI 'module remove' command now deletes files recursively
WFLY-1913 fixing module add command with letter drive in its resource path on Windows
WFLY-1914 Fix application client container startup problem https://community.jboss.org/message/833258#833258
WFLY-853 directory names with spaces and ampersands supported in vault.bat
WFLY-743 Ability to enable/disable a user

add-user script has now the ability to enable or disable a user with the
command line arguments --enable and --disable.
When enabling or disabling an existing user, the password is not required. Ex :
./add-user.bat -u ggrossetie --disable
WFLY-743 Ability to enable/disable a user in interactive mode
[WFLY-1845] Upgrade HornetQ to 2.4.0.Beta1

* upgrade HornetQ to 2.4.0.Beta1
* use a pooled connection-factory as Java EE's default JMS connection
  factory
* do not enlist the XA resource in JMSContextProducer when a transaction
  is active, HornetQ's XA connection is taking care of it
[WFLY-1287] Provide JMS Default ConnectionFactory

* use java:jboss/DefaultJMSConnectionFactory binding to provide the default JMS
connection factory to deployments
* simplify the destination injection
[WFLY-1337] JMS Destination definitions

simplify code
[WFLY-1337] Support JMSConnectionFactoryDefinition

* parse deployment descriptor and annotations for JMS connection factory
  definitions and create manageable pooled connection factory for each
  definition
* add a createBinderService boolean to ResourceAdapterActivatorService
  to be able to prevent it from creating a binder service. When a JMS
  connection factory is defined by annotations or DD, the
  BinderService is already created before calling the
  DirectJMSConnectionFactoryInjectionSource.getResourceValue() method
fix MDB tests

* with JMS 2.0, the behaviour of ConnectionFactory.createSession() has
been clarified:

> In a Java EE web or EJB container, when there is an active JTA
> transaction in progress:
>
> Both arguments transacted and acknowledgeMode are ignored. The session
> will participate in the JTA transaction and will be committed or rolled
> back when that transaction is committed or rolled back, not by calling
> the session's commit or rollback methods. Since both arguments are
> ignored, developers are recommended to use createSession(), which has no
> arguments, instead of this method.
> In the Java EE web or EJB container, when there is no active JTA
> transaction in progress:
>
> The argument transacted is ignored. The session will always be
> non-transacted, using one of the two acknowledgement modes
> AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE.
> The argument acknowledgeMode is used to specify how messages received by
> this session will be acknowledged. The only permitted values in this
> case are Session.AUTO_ACKNOWLEDGE and Session.DUPS_OK_ACKNOWLEDGE. The
> value Session.CLIENT_ACKNOWLEDGE may not be used. For a definition of
> the meaning of these acknowledgement modes see the links below.

However, the MDB contract in EJB 3.2 spec (§ 5.4.6) specifies that:

> The PostConstruct lifecycle callback interceptor method executes in an
> unspecified transaction and security context.

This means that the behaviour of ConnectionFactory.createSeesion is
unspecified in @PostConstruct since the transaction context is itself
unspecified.

After some debugging, it appears that in WildFly, there *is* a
transaction when @PostConstruct method is called. This implies that the
JMS session is created to participate in *this* transaction.

Later on, when the MDB's `onMessage()` is called, it is in *another*
transaction and the JMS session will not participate (meaning the reply
message is not sent and the tests failed)

It was working before with JMS 1.1 because the JMS sessions was not transacted
(the createSession contract was not specified) and the message was sent
outside of the transaction required by the MDB's `onMessage()` method.

Creating a JMS context (equivalent to a connection + session) inside the
`onMessage()` method makes sure the JMS session is created with a
correct transaction context.
In addition, there is no benefit to keep the JMS connection as a MDB
field since it's using a pooled connection.
Snapshot on hornetq - do not merge this