On 11/11/11 8:50 AM, Max Rydahl Andersen wrote:
On Nov 11, 2011, at 15:40, Jason T. Greene wrote:
> On 11/11/11 4:48 AM, Max Rydahl Andersen wrote:
>> …but now i'm truly happy we got Filesystem deployment "api" so I
>> can actually work without users setting these things up - or will
>> that also be disabled by default ?
>
> You keep saying this, but doesn't this feel a little bit ironic to
> you? I mean you were constantly demanding a management API, and now
> that we have one you can't stop looking for ways not to use it.
I never demanded a management api that couldn't be used for
incremental deployments - I also never wanted one for deployments if
it required full access to a running server.
I did demand a File API so I knew I could actually interact with a
local server no matter if it is running or not and from *any* tool
that already exist with or without management api available.
I believe the words you used were "REST API". Normally I wouldn't say
anything, but I'm a little tired of this repeated "dig".
The thing we like management API for is to check server is running,
graceful shutdown and to query for status of things.
Doing simple things like deploying app, datasource and queues should
be doable without a lot of overhead.
It's great the management API can do it but with it now being default
secured even for 127.0.0.1/localhost its not the first thing I would
use.
Note, we will make this easy to use, but for the cases of server not
running during deployment (local setup, preparation of a server, you
don't want to have it running etc.) or the management API not being
available (OpenShift and others and just plain remote server which
only exposes SSH/SCP) there the File API is tremendously useful.
And its much more universal.
Yes we all know your opinion. Honestly I don't care whether you use it
or not, but it's never going to do more than drop deployments in
standalone mode.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat