JBossDeveloper

For socket-binding-group I'm going to:

1. Change the "extends" attribute to a "include" child element, consistent with the handling in <profile/>
2. Make the "default-interface" attribute required. It would be quite unusual not to need to set it, and for those cases a minor inconvenience to have to set it. Making it optional makes it too easy to screw up the config.

Emanuel's been working the actual service implementation; see http://github.com/emuckenhuber/jboss-as/tree/sockets

A few comments:

1) We need to figure out where this should live. The domain/ module is fine for now.

2) I think we lose track of the SocketBindingElement "name" and Interface element "name". That is if we want to show a view of what the open sockets are we'd want to include that name information, particularly for SocketBindingElement. AFAICT we'd have to jump through hoops to get back from the InetSocketAddress to the SocketBindingElement.name

3) We should add an optional "description" attribute to SocketBindingElement.

4) I'll assign you the socket-related schema/domain model JIRAs; those are mostly done, but you should take ownership of the whole area for now.

I love how each socket and network interface is an injectable service! :-) Integration of a socket into a consuming service is going to be so easy!

Good point on the graceful shutdown aspect. Can you open a JIRA for that?

I don't want to let that block the immediate goal of getting a server running with remote JNDI, but we for sure need to think through in more detail those kinds of things -- define clearly the contract between these networking services and the services that use them. The graceful shutdown is a key bit.

Re: the description I just meant some useful to an admin text that could show up in a gui beyond what comes from <socket-binding name="remoting".../>. When I wrote it I thought the person writing the domain.xml could provide that:

<socket-binding name="remoting" desc="The remoting socket"/>

But my lame example above is probably what the poor admin would get (if anything) in 99% of cases. So, yeah, maybe much better is if the service consuming the socket binding somehow provides some useful information about what the socket is.