[jboss-as7-dev] Modeling Management Objects (was: birth of "console ui" in eclipse)

[Jason Greene]

Comments inline

Sent from my iPhone

On Mar 1, 2012, at 5:11 PM, Rob Cernich <rcernich at redhat.com> wrote:

> ----- Original Message -----
>> 
>> 
>> Sent from my iPhone
>> 
>> On Feb 29, 2012, at 12:23 PM, Rob Cernich <rcernich at redhat.com>
>> wrote:
>> 
>>>> I know very little about AutoBean framework so cannot say how/if
>>>> it
>>>> will work.
>>> 
>>> The framework creates a dynamic proxy for a bean interface which is
>>> backed by JSON, and can serialize object instances to JSON.  The
>>> shared component would be the interfaces.  The nice bit here is
>>> that it really simplifies the task of converting to/from JSON
>>> (much easier than managing ModelNode objects).
>> 
>> That's a subjective argument. The amount of code to build a DMR
>> request is roughly equivalent to the amount used with static
>> javabeans. The trade-off is giving up nice compiler static typing in
>> favor of being able to handle forward and backwards compatibility,
>> supporting dynamic clients, and being friendly to detyped languages.
> 
> It certainly is subjective, but my preference is:
> 
>  String foo = bar.getFoo()
> 
> over:
> 
>  String foo;
>  if (barNode.hasDefined("foo")
>    foo = barNode.get("foo").asString();
>  else
>    foo = null;

That's actually a bug we haven't due to. compatibility implications(asString should have returned null on an undefined model node) We do intend to fix it with a flag before EAP6.

In any case, when it still exists more succinct java code is:

String foo = node.hasDefined("foo") ? node.get("foo").asString() : null;

Or 
node = node.get("foo");
String foo = node.isDefined() ? node.asString() : null;

> 
> The notion of static typing is more philosophical.  (I won't start a philosophical debate.)

No one can deny the technical benefits of static typing and you certainly don't have to convince me of them. My point was that as with anything there are trade offs. Java's type model isn't flexible enough to meet the requirements for compatibility and dynamicity that we needed in the management API. 


> 
>> The first management prototype was static and attempted to solve
>> these issues part way, but it turned out to not only fall short but
>> was also cumbersome from a long term maintenance standpoint. A
>> client had to have a jar for every subsystem that it potentially
>> used, so you factor in the limitations of the Java type system,
>> which leads to multiple additional interfaces or multiple jars for
>> multiple versions and it gets messy pretty quickly.
> 
> That is true, but now one is coding directly against the schema.  If the schema changes, I may not need to rebuild, but if "foo" becomes "fu" it's broken either way.  Now I need to scour my source for instances of "foo" and change it to "fu," but luckily I've wrapped all my ModelNode manipulation with my own API (whether that's static string variables or something more sophisticated), so my search scope is limited.  (Add arguments for or against static typing...)

It's not just name changes. Add a method to a Java interface and implementations will no longer compile. Add fields and the serialization format changes. Note this is not just about clients it's also about the providers and their ability to communicate with different versions of each other (forward and backward).

> I can see where this would be burdensome if changes were made to a part of the schema that you weren't using.  (Then again, the classes associated with those areas would never be loaded, so it wouldn't matter whether I rebuilt my library or not.)
> 
> The real benefit here is that the provider is free to change the structure without worrying about breaking clients, or requiring them to recompile.  However, if the client is impacted by the changes, they'll be forced to update their library anyway.  And maintenance is pushed onto them by forcing them to accommodate for various versions of the schema.  Continuing the example:
> 
>  String foo;
>  if (bar.hasDefined("fu"))
>    foo = bar.get("fu").asString();
>  else if (bar.hasDefined("foo"))
>    foo = bar.get("foo").asString();
>  else
>    foo = null;
> 
> (Perhaps too trivial an example, as it's more likely that structural changes will occur, as opposed to simple name changes, but it illustrates the point.)
> 
>> I have always thought a stub compiler based on DMR descriptions would
>> be a nice way to bring back static typing without hampering the
>> model. A nice side project for someone...
> 
> 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<Bar> newBar();
>  }
>  Bar bar = AutoBeanCodex.decode(barBeanFactory, Bar.class, barNode.toJSONString(true)).as();

I take it this imposes a particular data format?

> 
> In my original post, I was simply asking if anybody had attempted to use the AutoBean framework outside a GWT environment and whether or not it would be beneficial to reuse a set of interfaces representing management objects (e.g. interface Bar above).  It sounds like the answer to the latter is, "We advise against that."
> 
> Best,
> Rob