> I know very little about AutoBean framework so cannot say how/if
> 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
> hard-binds/limits itself to specific versions of runtimes/admin
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
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 ?