Type: Feature Request
Status: Resolved (View Workflow)
Affects Version/s: None
Fix Version/s: 7.1.0.Beta1
Component/s: Domain Management
Affects:Documentation (Ref Guide, User Guide, etc.), Release Notes, Compatibility/Configuration
Support configs for remote interfaces and socket bindings in the domain model. See referenced dev list thread for a use case, as well as my comment on https://github.com/jbossas/jboss-as/pull/192.
From the dev list thread:
Another thing to deal with is interface resolution. With the exception
of the "<loopback address="127.0.0.4"/> criteria Scott added, resolving
an interface means finding a NIC on the machine that matches the
criteria. If that can't be done, it's an error condition. To avoid that
there would need to be some new criteria added (e.g.
<remote-inet-address value="10.0.0.53"/>) or an attribute added to the
existing inet-address criteria (e.g. <inet-address value="10.0.0.53"
A minor issue relates to changing the configuration of a socket binding.
Basically, we try and track whether you've used a particular
SocketBinding service to open a socket; if not we let you change the
binding config without requiring a server restart or reload. This
connection-url stuff won't use the SocketBinding service to create a
socket, so the binding will be editable at runtime with no
reload/restart required. But there's no dependency relationship between
the binding and the datasource, so that change is not going to be
reflected in the datasource. This is just an example of the general
problem with using system properties as an injection mechanism.
I don't think this last point is a blocker, it just requires documentation.