activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Handling XSDs and Spring 2 XML processing etc.
Date Fri, 15 Jun 2007 10:08:41 GMT
On 6/15/07, Endre StĂžlsvik <Apache@stolsvik.com> 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?

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

I think I'd prefer an alias to 'the latest spec' instead.

say 4.x would resolve to the latest/greatest spec etc.



>    (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! :)

Fancy submitting a match? :)


>    META-INF/MANIFEST.MF could also do with a shine (I've commented on
> that before),

Ditto :)

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

Its certainly possible; though I do worry about huge jars with every
release adding a big XSD inside it.

So far am leaning towards the 4.x idea and just including the latest schema

-- 
James
-------
http://macstrac.blogspot.com/

Mime
View raw message