Re: [jbosstools-dev] [jboss-as7-dev] Modeling Management Objects (was: birth of "console ui" in eclipse)
>
> [snip...]
>
>>> While it may not generate the code for you, the AutoBean
>>> framework
>>> allows you to wrap the underlying JSON with an API. Continuing
>>> the above example:
>>>
>>> interface Bar {
>>> String getFoo();
>>> void setFoo(String value);
>>> }
>>> interface BarBeanFactory extends AutoBeanFactory {
>>> AutoBean newBar();
>>> }
>>> Bar bar = AutoBeanCodex.decode(barBeanFactory, Bar.class,
>>> barNode.toJSONString(true)).as();
>>
>> I take it this imposes a particular data format?
>
> Yes. JSON.
Right, but does it require a particular structure, or can you map say
something to a map instead of an object etc?
I believe so. In addition to model structure, operations can also be supported using the
"Category" mechanism (class associated with the factory, which contains static
methods implementing the operation). Here's the documentation (sparse as it is):
http://code.google.com/p/google-web-toolkit/wiki/AutoBean
Just to clarify my original intent behind an API: I was only considering interfaces, not
implementations. Those interfaces would collect cruft as the API evolves. This implies
the interfaces would be backward compatible as long as desired. Also, I believe that
maintaining an interface would help keep developers "honest," highlighting the
fact that management details are API (i.e. change the structure, roll the version and
update the interface; I suppose that implies the version can be queried). In the end, a
client includes a JAR that defines the interfaces, implements those however they want
(e.g. AutoBean framework, ModelNode, etc.) and they're off. They don't need to
maintain a parallel set of interfaces. And, if they're using an older set of
interfaces with a newer server version, they should still get the benefit of partial
operability, as the implementations are ultimately working on the DMR structure (strings
and whatnot).
Best,
Rob