WFLY-2423: support for resource injection with non java: jndi names; better approach for detecting url connection factories; cleanup/optimization through resource injection processors logic sync and merge of optional with non-optional lookup injection source
WFLY-3136 SRV 7.7.2 non-compliance
Protected from access by other nodes via eager lock, but only when pessimistic locking is enabled.
WFLY-2976 use http-remoting as default for the remote-outbound-connection
[WFLY-3160] Add sun/security/action path to sun.jdk module.
Merge pull request #6081 from pferraro/ejb

WFLY-3136 SRV 7.7.2 non-compliance
Merge pull request #5445 from emmartins/WFLY-2423

WFLY-2423: support for resource injection with non java: jndi names; bet...
Merge pull request #6082 from ctomc/cleanup

WFLY-2976 use http-remoting as default for the remote-outbound-connection
cli: fixed conflicts after merging https://github.com/wildfly/wildfly/pull/5912 and https://github.com/wildfly/wildfly/pull/6019
Merge pull request #6086 from darranl/WFLY-3160

[WFLY-3160] Add sun/security/action path to sun.jdk module.
Merge pull request #6085 from jmesnil/WFLY-3159_upgrade_genericjms_ra_1.0.3.Final

[WFLY-3159] Upgrade Generic JMS RA to 1.0.3.Final
[WFLY-266] Notification Support

* add notifications to AS7 resources description
  * notifications are described in :read-resource-description operation
    if the notifications boolean is true
  * all resources emit 3 types of notifications by default:
    * resource-added
    * resource-removed
    * attribute-value-written
* NotificationDefinition let any resources describe the notifications
  they can emit by registering them in the
ManagementResourceRegistration
* add NotificationSupport to let AS7 resource register/unregister
  notification handlers and emit notifications
* emit notification for resource added/removed and
* attribute-value-written
  directly from the AbstractOperationContext.
* emit notifications for server lifecycle notifications (server-started,
  server-stopped, server-restarted, server-killed & server-destroyed)

Notification emitted by OperationContext.emit(Notification) are
effectively sent at the end of the operation execution if it is
successful. This ensure that the order of notifications emitted by a
single OperationContext will be received in the same order (unless
they are emitted during the ResultHandler execution).

JIRA: https://issues.jboss.org/browse/WFLY-266
add support for JMX notifications