Hi guys I'm on the tooling side of the story and I tried to figure out how to access the as7 managent model. I unfortunately could not find enough so far. I found extensive documentation here: http://community.jboss.org/wiki/DetypedDescriptionoftheAS7ManagementModel but the part that's should explain how to access the model is still marked as TODO. I found some informations on RHQ (http://www.rhq-project.org/display/RHQ/Talking+to+the+JSON+api) and some code in the as7-console (https://github.com/heiko-braun/as7-console/blob/master/standalone/src/mai...). Is there any further documentation that would help me? Thanks! André _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 3/22/11 1:15 PM, Brian Stansberry wrote: > I'll update that wiki today. Done.

> In the meantime (and probably better anyway) best is to look at some of > the demos in the AS source tree's demos/ module. E.g. > > https://github.com/jbossas/jboss-as/blob/master/demos/src/main/java/org/j... >

There is an HTTP interface that can take requests in either JSON or in

Hi Jason thanks for the further insights! > There is an HTTP interface that can take requests in either JSON or in > base64 encoded dmr binary format. We don't call it REST though because > "invoking" an arbitrary management operation (e.g. "clear auth cache") > does not meet the REST purity definition. hmm, to be honest I dont really understand why a RESTy semantic (ex. post to or delete to the uri of the cache resource) would not allow this operation. But I might miss something here since I do not have the same background. > > Keep in mind that the remote Java API will be the easiest to use from > Java, since it will handle all the transport stuff for you, and > exposes a nice API for working with detyped data. The main focus of > the HTTP interface is supporting non-Java clients (i.e. scripting > languages, and the console which is JavaScript based) > oh, looks like I missed this one. Guess using the java API would be the better choice for me then. Is there any documentation about it? Cheers André _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I have a simple Maven plug-in using the Java API. It's probably not 100% complete yet, but it works for now. https://github.com/jamezp/jboss-as-deploy-plugin Anyway, you'll see how simple the Java API is for deploying, redeploying and undeploying. I'm sure the API does a lot more than what I'm doing with it, but it's a simple example.

From what I understand the only way "out" of this is to use http or dmr api's since that is/should be stable and does not break as easily as a java library dependency.

-- James R. Perkins On Wed, Mar 23, 2011 at 13:19, André Dietisheim <adietish(a)redhat.com&gt; wrote: Hi Jason thanks for the further insights! > There is an HTTP interface that can take requests in either JSON or in > base64 encoded dmr binary format. We don't call it REST though because > "invoking" an arbitrary management operation (e.g. "clear auth cache") > does not meet the REST purity definition. hmm, to be honest I dont really understand why a RESTy semantic (ex. post to or delete to the uri of the cache resource) would not allow this operation. But I might miss something here since I do not have the same background. > > Keep in mind that the remote Java API will be the easiest to use from > Java, since it will handle all the transport stuff for you, and > exposes a nice API for working with detyped data. The main focus of > the HTTP interface is supporting non-Java clients (i.e. scripting > languages, and the console which is JavaScript based) > oh, looks like I missed this one. Guess using the java API would be the better choice for me then. Is there any documentation about it? Cheers André _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

>> I have a simple Maven plug-in using the Java API. It's probably not >> 100% complete yet, but it works for now. >> https://github.com/jamezp/jboss-as-deploy-plugin >> >> Anyway, you'll see how simple the Java API is for deploying, >> redeploying and undeploying. I'm sure the API does a lot more than >> what I'm doing with it, but it's a simple example. > > There is no doubt that the Java API is better - our concern is if > that Java API will be back/forward compatible with releases of AS > 7.x/EAP 6.x or if tools need to have a separate bundle compiled for > each version (biggest problems we've seen previously is that even > when the api's didnt change the serialization did and boom - tools > are broken). Yes, that's the whole point of the detyped API. It makes long-term compatibility much more practical.

> hmm, to be honest I dont really understand why a RESTy semantic (ex. > post to or delete to the uri of the cache resource) would not allow this > operation. But I might miss something here since I do not have the same > background. It's purely an issue of complexity. A more RPC approach has the benefit that any subsystem can expose any runtime call it wishes to by just adding a method and a mapping. In a REST approach you have to come up with clever ways to map what ever you are doing to a CRUD resource tree, this puts a lot of burden on subsystem developers.

Also note that we support complex transactional operations (e.g. apply this change to 15 servers and if more than 4 of them fail roll it back) which do not map cleaning to a simple READ/UPDATE/DELETE URL model. You end up having to create virtual session specific objects for every client.