Mismatch between application resources and access control configuration

When configuring an application resource it is often not possible to make use use of it in the console. This is because the ability to configure application resources is in most cases more fine grained than the hard-coded configuration of access control resources bound to a presenter.

This becomes evident, when you make the data-source resource an application resource:

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)

The console won't let you edit datasources as a deployer unless you also make the xa-data-source an application resource, because the datasource presenter is configured as

@AccessControl(resources = {
    "/{selected.profile}/subsystem=datasources/data-source=*",
    "/{selected.profile}/subsystem=datasources/xa-data-source=*"
})

and the current security context implementation uses an "all-or-nothing-approach".

Making the xa-datasources an application resource might be a workaround here. However for other use cases like JMS this is not possible, since the JMS presenter uses many resources which cannot be enabled as application resources.