Agentless Backup is Not a Myth

JBoss World is a pretty calm place - even Marc Fleury is pretty laid back (I suppose he has cause to be). But there was a flurry of interest when a speaker announced that the next smoother, faster JBoss architecture would do without JMX (Java Management Extensions, which JBoss currently uses, not for management particularly, but to start services etc). As I heard it, some panic ensured, because JBoss' customers may well be using JMX with JBoss.

But I'm assured, there's no problem - the new JBOSS micro-kernel will still provide a JMX interface and translate calls into whatever it uses internally. So that's OK, then - see here, for some pointers to the JBoss status quo; and here, for discussion of the rearchitecting of the microkernel, including this statement: "we will continue to support JBoss 4 and earlier JMX service beans".

Conventional vendors dictate to their customers - "you must use this new API, you must upgrade now". Since Open Source customers have the source code, you can't dictate to them.... That's one of the selling points.

So, it seems strange to me that a JBoss speaker could have given the impression that JBoss was was trying to force change on its users, even if it was only one speaker and a few users... And it's odd that anybody in the audience could think that it'd do such a thing. I do hope "professional open source" isn't so different....

But I'm now sure that there's nothing in this, just a misunderstanding. Nevertheless, it made me think that while some JBoss customers will miss the old exciting, even opinionated, JBoss, others may well welcome a slightly less exciting maturity, which will come with Red Hat ownership ®.

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery