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 10:01:05 GMT
>> > 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? 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)

   (I still, though, think the included (the one inside the jar) could 
benefit from having the version number attached (and also have it inside 
the actual schema, as a comment??). I don't know if I've gotten through 
on that point - but i _love_ explicitness! :)
   META-INF/MANIFEST.MF could also do with a shine (I've commented on 
that before), and all files all over should have the version number 
tagged on. The point is that if you see ANY such artifacts outside their 
container, or "outside their scope", it is very nice to be able to 
"backtrack" to what it belongs to and where it came from. It usually 
doesn't take that much labor to include it, but gives many small 
benefits ever after.).

  (And when it comes to including the older XSDs in new releases - 
wouldn't that just be to suck in all the XSDs that are laying around on 
the dist-site when cutting a new release?)

Kind regards,

View raw message