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

[Rob Cernich]

----- Original Message -----
> >>>> 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;
> > 
> > The notion of static typing is more philosophical.  (I won't start
> > a philosophical debate.)
> 
> This is all good as long as there are ways to handle:
> 
> if (runtime.supportsX()) {
>    node.doX();
> } else {
>    node.doY();
> }
> 
> And that you can have doX() and doY() even if the schema for the
> latest version only contains support for doX().
> 
> >> 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...)
> > 
> > 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.)
> 
> Yes - so can you support/handle such changes via AutoBeans ?


I believe so.  You would simply need to add the changes to your interfaces.  For example:

  interface Bar {
    /*
     * @since 1.0
     * @deprecated 2.0
     */
    String getFoo();
    void setFoo(String value);

    /*
     * @since 2.0
     */
    String getFu();
    void setFu(String value);
  }

And because the interface is simply wrapping JSON, you still get the "benefit" of having your features "mostly" work if there were changes to the underlying structure.


> >> 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();
> > 
> > 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."
> 
> For the question on usage within AutoBean then my reading on it
> sounds like it should technically be doable (you might need to use
> eclipse buddyclassloading to make it work since the fwk need to load
> user classees - I didn't find a way to set the classloader used but
> that might just be me not looking closely enough).
> 
> But sharing classes with runtime specific binaries I do advise
> against by default since it more often than not cannot be
> encapsulated to allow the client to use multiple versions without a
> massive hassle.
> 
> /max
> 
> 
> 
> 
>