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

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

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

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

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

> 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.  This is really no different than depending on any other API, like Eclipse or OSGi.  Those just happen to have a well defined process for managing the evolution of their API, which is the crux of the problem here.

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

Best,
Rob