activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <>
Subject Re: Handling XSDs and Spring 2 XML processing etc.
Date Thu, 14 Jun 2007 21:21:13 GMT
James Strachan wrote:
> On 6/14/07, Endre Stølsvik <> wrote:
>> > A few issues have come up in this rather long and complex set of JIRAs.
>> >
>> > (i) Should we encourage folks to put the exact version of ActiveMQ
>> > they are using in their configuration files? Or should we encourage
>> > them to use a non-versioned XSD that at runtime will be resolved
>> > against the activemq-core.jar? See
>> > for background.
>> >
>> > Am thinking we default to the non-versioned one; then if folks really
>> > wanna use a versioned one, they just add the version in themselves.
>> I think:
>> 1) That you shouldn't change the schema as often as you change version
>> of AMQ - the schema _ought to_ be more stable. If not, then maybe you
>> should consider making the XSD more "future-proof" by adding name/value
>> properties or whatever so that even though you come up with some new
>> fancy stuff, the "old" config files can still be used to config it.
> The schema is code generated from the java code, javadoc and so forth.
> Typically it never changes in backwards-incompatibile ways; but we
> often add new atributes and whatnot (which are usually optional), or
> make nicer/more richer/better documented XSDs etc.
> Certainly users shouldn't have to upgrade to newer XSDs if they don't
> wanna use the new features of the newer releases.

Yes, this is really my point: I gather there are lots of people that 
just upgrade to a newer version to get the new speed benefits, stability 
benefits etc, without AT ALL changing their config - or just adding some 
new queues, typically using the existing nomenclature.

> I'd rather not use generic key/value pairs; as this kinda breaks the
> whole point of using an XSD in the first place (folks can use plain
> spring for key/value pairs). FWIW folks should be able to mix and
> match <property key=".." value="..." from Spring with the ActiveMQ
> XSDs...

Yeah, I see that. I guess simply _adding_ a new property won't do much 
harm - but you should then have some system that checks this, and don't 
suddenly change the syntax or some attribute name between revisions and 
minor releases.

>> 2) Since any IDE will use the URL, and not the spring.schemas, this is
>> one reason you should encourage the use of exact versions. Or else my
>> perfectly valid spring file suddenly will start to reek of errors, even
>> though it is perfectly Okay when running.
> Most IDEs allow you to specify which physical XSD maps to a remote XSD
> or namespace URI.

I really didn't know that Eclipse could do that - but then again I have 
never really looked, as I find the thought totally against the whole 
idea. (I did think that you could point it at a local copy, though - and 
as such you could "fake" this - but..)

> Its a tradeoff - do you want to have to update your
> configuration files after every release (to take advantage of possibly
> new attributes available), or do you want to just hide that stuff in
> your IDE configuration. I can see the benefits of either approach.
> Users can choose either way themselves.

I actually can't see the benefit of the one way you suggest: if I, as 
the second developer to that project, have to open up that file, I'd 
rather like it very much of the file actually specifies directly and 
explicitly which schema is in use, so that I don't have to dig this up 
from the jars, or ask the old developer, that left the shop 5 months 
ago, about what he had configured in his IDE?!

> I guess it might be better if the activemq.xml in each release binary
> referenced the exact version number; we'd then need to change the
> release process to substitute in the release number in the
> activemq.xml file when making the distro.


> Incidentally; one of the nice benefits of the spring.schemas file is
> it means that your application won't try and connect to the internet
> at runtime to load the XSD (with firewalls & proxies that is not
> always possible). 

One of the benefits?! Isn't it _the_ benefit? That was what bug 1016 
really was about - the ugly naming was totally secondary.

> If users stuck on (say) 4.1 of the XSD and we
> released 4.1.2; then the entity resolver would not be able to resolve
> the 4.1.2 schema; so your application could break if you upgrade to a
> newer version of ActiveMQ.

Why is that?

> The great thing about not using a version number in the users config
> file is; ActiveMQ will always use a local XSD and never use the
> internet; this is a big benefit to lots of users.

You can have multiple entries in the spring.schema, as you yourself 

You could also (orthogonal to the above suggestion) have multiple copies 
of the local XSD version, with version numbers. Keep the old ones around 
in newer distros?

>> 3) I think you could version the XSD for example "1.0" at this point,
>> and keep it _exactly that way_ till you absolutely have to stash in
>> something more, or change something, when you will release a "2.0". If
>> you then actually include two different parsers with the AMQ release
>> that includes the 2.0 format, then even my 1.0-configged application
>> will still work - ref any Servlet container. This is the OTHER reason
>> why you should encourage the use of exact versions.
> Its a bit hard to do that right now; we'd need some help (e.g. to be
> able to tell the difference between a better schema thats got more
> documentation & better validation rules versus something that really
> has changed).

The documentation part is totally irrelevant to the _running_ of the 
application, isn't it? So definitely, upgrade the docs and whatnot, but 
preferably not the "actual content" of the XSD, the syntax or naming.

> Though we welcome contributions if you can think of a way to improve
> our XSD release process & to alert users to real (v. synthetic) XSD
> changes etc

I do think that I at this point would use a prohibitively long time to 
get into the codebase to come up with better solutions. I'm just a 
backseat driver - feel free to ignore me!

Kind regards,

View raw message