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

[Max Rydahl Andersen]

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