HTTP transport

[Ladicek]

It would be useful to have support for HTTP transport, in addition to the native management protocol. Some operations can't be performed over the HTTP transport, though -- notably, anything related to CLI (i.e., all invocations of executeCli and certain subset of invocations of execute, even if we were able to parse CLI strings). Meaning that some methods of OnlineManagementClient would throw UnsupportedOperationException with the HTTP transport when they would work perfectly fine with native protocol.

For that reason, I think that maybe HTTP transport could maybe be configured in a slightly annoying way. But maybe that doesn't make a lot of sense.

This also incorporates HTTPS, which should reuse the SSL configuration bits from #93.

[Ladicek]

The HTTPS part can be left for later, especially if #93 will not be available in time.

[Ladicek]

Oh and FYI, I'd like to avoid adding external dependencies as much as possible. I realize that the HTTP client in JDK is a PITA, but it should be enough. Or, if we really need a library, it shouldn't have a lot of dependencies itself and should probably be <scope>provided</scope> (people typically won't use the HTTP transport, so there's no reason we should pollute their classpath).

[istraka]

I am thinking about creating class like HttpModelControllerClient implementing ModeControllerClient interface (probably not all methods?). Execute method would follow jboss http management api. Implemented in Java, ofc.
Is this approach OK?

[Ladicek]

Hm, OK, I was thinking more of an HTTP-based implementation of OnlineManagementClient, but I guess that HttpModelControllerClient would let us have a rudimentary CLI support? Probably with a bunch of limitations, but I'd say go for it.

[Ladicek]

Fixed by #109.