birth of "console ui" in eclipse

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
> >> That said, there is a lot of mileage to be gained by simply being
> >> able to use the AutoBean framework within Eclipse.  Does anyone
> >> have any experience using AutoBeans in an Eclipse or OSGi
> >> environment?  (In SY land, we're slowly moving to a place where
> >> our core management/configuration model API can be used in the
> >> tooling as well.)
>
> Oh and this is even worse now I reread it - having *hard coupled*
> dependencies to core from eclipse plugins is our biggest problem we
> have in Drools, Teiid and Modeshape.
>
> This causes *massive* problems from both user and plugin-dev side
> since each release of the plugin extremely easy becomes tied to
> specific versions of the runtime.
>
> Does the API allow decoupling ? (i.e. one option is the plugin to
> load dynamically the runtime jars from the targeted runtime)

See my previous response.  The real problem is the stability of those APIs.  No amount of decoupling allows you to instantly see new features or retract removed features, unless you're putting together a dynamic GUI, which is then limited in its usability (e.g. generic JMX consoles, generic WS testers, etc.; they get the job done, they adapt nicely, but they aren't very pretty).

Best,
Rob
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects

Stan Silvert
On 2/29/2012 1:32 PM, Rob Cernich wrote:
> See my previous response. The real problem is the stability of those
> APIs. No amount of decoupling allows you to instantly see new features
> or retract removed features, unless you're putting together a dynamic
> GUI, which is then limited in its usability (e.g. generic JMX
> consoles, generic WS testers, etc.; they get the job done, they adapt
> nicely, but they aren't very pretty). Best, Rob
> _______________________________________________ jboss-as7-dev mailing
> list [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev 

I don't see any reason why a dynamic GUI must have poor usability.  
This might have been true for the JMX console, but the management model
provides tons of metatdata.  It even provides localized help text.   I
believe it is possible to put together a very nice GUI for it that is
completely dynamic.  The CLI GUI is already decent and it required very
little code.  I see nothing that stops it from becoming extremely usable
and useful.

Stan

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects

Jason T. Greene
That was certainly the intention when we designed the management API.

Sent from my iPhone

On Feb 29, 2012, at 1:05 PM, [hidden email] wrote:

> On 2/29/2012 1:32 PM, Rob Cernich wrote:
>> See my previous response. The real problem is the stability of those
>> APIs. No amount of decoupling allows you to instantly see new features
>> or retract removed features, unless you're putting together a dynamic
>> GUI, which is then limited in its usability (e.g. generic JMX
>> consoles, generic WS testers, etc.; they get the job done, they adapt
>> nicely, but they aren't very pretty). Best, Rob
>> _______________________________________________ jboss-as7-dev mailing
>> list [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev 
>
> I don't see any reason why a dynamic GUI must have poor usability.  
> This might have been true for the JMX console, but the management model
> provides tons of metatdata.  It even provides localized help text.   I
> believe it is possible to put together a very nice GUI for it that is
> completely dynamic.  The CLI GUI is already decent and it required very
> little code.  I see nothing that stops it from becoming extremely usable
> and useful.
>
> Stan
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Max Rydahl Andersen-2
In reply to this post by Rob Cernich
>> 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).

ok

>> What I'm most worried about though is any eclipse tooling that
>> hard-binds/limits itself to specific versions of runtimes/admin
>> apis.
>
> You cannot avoid this problem.  

of course you can - i.e. JDT supports Java 1 to 7 with one set of tools, JBoss Server adapter supports AS 3 to 7 with one set of tools.

Reason: not tied to specific runtime, especially not at compile/build time.

The problem comes when you rely on bundled runtime - thats shown to be problematic with Hibernate when we reached Hibernate 4 (Hibernate 3 series was okey), Drools and Teiid especially have challenges here because the plugin is way too tied to specific runtime.

Which is a seriously bad thing since users/developers uses multiple versions in day-to-day work (just think maintanence and new development - one is targeting SwitchYard 1.0 another SwitchYard 1.2 for example). Would you expect users to uninstall your SwitchYard 1.2 plugin and install SwitchYard 1.0 plugin when they switch branch ?

> Ideally, the best solution is to have well defined rules regarding the evolution of the API.  In my opinion, the management model should be treated no differently than any other public API provided by the server.

Yes - which is perfectly doable if no tie in to binary apis.

> Back in the real world, this may require tooling specific to each version.  (The tooling is different between AS 5 and 7.)

Yes, but it is handled by the same tools - not different tooling.

>> Will this allow you to support multiple versions better or worse ?
>
> No difference here.  If the API changes between releases, you're stuck either way.  (Although, it may be better.  Because the framework simply proxies back to JSON, added structure will be invisible and removed structure will be null; i.e. you won't really see the changes.  It may be odd for the user, wondering why some setting appears to be ignored, but...)

Sure - and as long as there is a mechanism in the plugin to handle such differences then its all good.

>> What I understand is you would be using/linking with the Admin
>> console code which would tie you 100% to a specific version ... that
>> sounds like a bad approach to me ?
>
> Actually, you would be tied to an API specific to the management structure for each version of the runtime.  The console and other bits of tooling would depend upon that API.  If the API is stable between releases, then all is well.  If the API changes, then the console and other bits of tooling will need to be updated.  

if by updated you mean to *add* support for the differences, i.e. have a notion of SwitchYard runtimes - i.e. to support 1.0 *and* 1.2 in the same plugin; just like Eclipse JDT supports multiple version of java and JBoss server adapter multiple versions of JBoss - then yes I agree.

If you mean, "oh now SwitchYard 1.2 is out we will update the plugins that before supported 1.0 to just target 1.2" then I disagree ;)
 
> This is really no different than depending on any other API, like Eclipse or OSGi.  

oh it is - in eclipse/osgi or just plain java its extremely annoying/hard to handle loading multiple versions of an api.

We do some for AS 7 but its tricky since it in worst case require us to bundle multiple versions of AS7 client jars - for now we dont have to because AS 7 team been good at keeping them API compatible (currently we use native interface, I would prefer to use the http one since it would reduce the risk of binary breakage)
 
> Those just happen to have a well defined process for managing the evolution of their API, which is the crux of the problem here.

Yup - which is why tools need to cater for reality ;)

> That said, having a specific project(s) for a management model(s) might help ensure the stability of the API.

not sure what you meant here ?

/max
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Max Rydahl Andersen-2
In reply to this post by Rob Cernich
>> Does the API allow decoupling ? (i.e. one option is the plugin to
>> load dynamically the runtime jars from the targeted runtime)
>
> See my previous response.  The real problem is the stability of those APIs.  No amount of decoupling allows you to instantly see new features or retract removed features, unless you're putting together a dynamic GUI, which is then limited in its usability (e.g. generic JMX consoles, generic WS testers, etc.; they get the job done, they adapt nicely, but they aren't very pretty).

I've never expected to magically see new features pop up in tools ;)

I do though expect tools to support multiple versions of runtimes and preferably not break completely in the instance that a new version is out of runtime....and yes this assumes the runtimes doesnt change their "api"'s radically (i.e. our AS tooling built for starting/stopping AS 3.x continued to "just work" all the way up to AS 5 for most things and more or less gracefully handled differences) . But of course too big changes sometimes do happen and a new release of the plugin needs releasing to support them - i.e. AS 5->6 and especially AS 6->7 had changes that prevented launch.

My point is just that the plugin should at least handled multiple versions - and then its more or less up to the runtimes to decide how much change they do or not do to ensure tooling doesn't break on every new release.

/max
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Jason T. Greene
In reply to this post by Rob Cernich


Sent from my iPhone

On Feb 29, 2012, at 12:23 PM, Rob Cernich <[hidden email]> 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.

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.

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...
 
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
----- Original Message -----

>
>
> Sent from my iPhone
>
> On Feb 29, 2012, at 12:23 PM, Rob Cernich <[hidden email]>
> 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;

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

> 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.)

> 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."

Best,
Rob
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Max Rydahl Andersen-2
>>>> 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 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





_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>
>
>
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Jason T. Greene
In reply to this post by Rob Cernich
Comments inline

Sent from my iPhone

On Mar 1, 2012, at 5:11 PM, Rob Cernich <[hidden email]> wrote:

> ----- Original Message -----
>>
>>
>> Sent from my iPhone
>>
>> On Feb 29, 2012, at 12:23 PM, Rob Cernich <[hidden email]>
>> 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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Ales Justin
>> 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.

We have that -- statically typed management in AS5/6, EAP5 -- and as Jason said, it never scaled;
no way we could (and actually didn't) get such great support for all diff (sub)systems in so little time as AS7 did.

-Ales


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
In reply to this post by Jason T. Greene

[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.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

jtgreene
Administrator
On 3/5/12 8:49 AM, Rob Cernich wrote:

>
> [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?


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modeling Management Objects (was: birth of "console ui" in eclipse)

Rob Cernich
> >
> > [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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12