activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Handling XSDs and Spring 2 XML processing etc.
Date Fri, 15 Jun 2007 03:41:31 GMT
On 6/14/07, Endre Stølsvik <> wrote:
> 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.
> Definitely.
> >
> > 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 release only includes the current generated XSD in the jar. So we
can't easily ship 'every possible old version of the XSD' inside the
jar as well. So version 4.1.2 will just include 4.1.2 of the XSD and
so just work with

If you're config file is using 4.1 or 4.1.1; then ActiveMQ will be
using the internet to resolve the XSD

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

Yes, but we've no easy build system to download and include every
version of previous schemas inside each release.

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

Thanks for volunteering to produce that patch :)

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



View raw message