James Strachan wrote:
On 6/15/07, Endre Stølsvik <[EMAIL PROTECTED]> 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
> http://activemq.apache.org/schema/core/activemq-core-4.1.2.xsd.
>
> 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 5.0.1.2.4.x.a.b. 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
http://activemq.apache.org/schema/core-2.
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,
Endre.
