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 Fri, 15 Jun 2007 11:16:31 GMT
James Strachan wrote:
> On 6/15/07, Endre Stølsvik <> wrote:
>> >> > 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
>> Not necessarily: IF you only have changed doc, OR only _added_ stuff,
>> then you could use the multi-line possibilities in spring.schemas to
>> "redirect" the older ones to the new included one - didn't you also
>> point this out, by suggesting that both the versioned file, and the
>> unversioned file, should have its own line in spring.schemas?
> But I thought you argued previously in this thread that you never
> wanted to change, silently, the 4.1 schema for 4.1.2 at runtime?

I gathered that we were talking about doc-fixes and _pure additions_ to 
the XSD at this point - not actual changes, syntactic nor names.
   (The point is that you did something way more radical than that 
between 4.1 to 4.1.1 - you made everything NOT WORK anymore, including 
existing installations that used 4.1 (since everybody had to download 
this over the net, due to FU spring.schemas)).

I assumed that you agree that if you folks change the XSD radically, so 
that older config files are known to not work, this should be explicit, 
not just going for the new version under the hood, guaranteeing that it 
won't work for upgrades. At least the error message could point this 
out: "this config file (xxx) is for the AMQ 4.x series, while you are 
now running on AMQ Please review the bla bla doc to 
upgrade your config."
   The most explicit you could do, I guess, is at that point to change 
the namespace URI - which I gather you already aimed at with the "1.0" 
in the URI now (not that it ever was used). For example change it to

>> Why not
>> just also add in the older lines, e.g. 4.1.0, 4.1.1 and so on, in there?
>>    This because any older XML files (the config files) would then
>> "compile against" the new XSD, without errors - and everyone would be
>> happy. If however anything came up, everyone would know just which exact
>> version of AMQ this file originally was written against (although, since
>> you won't distribute the older xsd's, you can now add new stuff to an
>> old config file, and it will still run - which I guess it shouldn't have
>> if you wanted to be totally correct)
> If there was ever an issue with 4.1.1 and the user wanted to go back
> to 4.1 XSD, they couldn't using this approach.

How could they, at any rate? Given a particular version of AMQ - unless 
you add explicit handling of the different config file versions (XSD 
versions) _in the AMQ code_, then it doesn't really matter which XSD I, 
in my XML config file, point at. If the _parser_ step parses it towards 
4.1 (by downloading the XSD over the internet), but your _config_ step 
expects 4.1.1, then it won't work nevertheless if there are inconsistencies.

Really, these small things aren't that important - the HUGE annoyance is 
now removed, things look considerably more consistent, and pretty much 
all is nice! However, it is of course worth trying to make the _future_ 
upgrade path as easy as possible for all parts involved, and in 
particular for the consumers - new versions shouldn't be a PITA to 
install - preferably it should simply be a jar-change, and .. that's it!

Kind regards,

View raw message