Jumping right into a previous discussion:
I'm curious about the question of hosting the mgmt console as I
assumed
it would live in the domain controller. I don't have my notes from
Antwerp available to double check, but isn't the domain controller just
another AS instance? If so why wouldn't it always live in that process?
No, a domain controller is not an EE-capable app server.* It's a
specialized java process that only supports required functionality. From
an external client POV, the functionality it needs to expose are:
1) A socket backed by a service that understands the proprietary Java
protocol we'll use for the detyped management API.
2) An mbean server and a JMX connector.
3) A socket backed by a service that understands HTTP/HTTPS and can
support our REST interface. Note that this does not require Servlet spec
support. Our thinking at this time is to base this on the lightweight
HTTP server in JDK 6.
* To be precise, a DomainController is a HostController whose host.xml
config tells it to load the domain controller module rather than making
a connection to a remote HostController.
If the DomainController (HostController) serves the REST API, the question would be how
wan't to build it.
I would propose RestEasy+TJWS [1]. TJWS has very small footprint, but still supports the
Servlet API.
In that case we would buy a suitable runtime for serving the admin console. It could
integrate through the REST API.
(or even GWT-RPC if we go that way)
If you skip RESTeasy, fleshing out the REST API becomes more work, but it would reduce the
dependencies.
Any thoughts on this?
Ike