James Strachan wrote:
On 6/14/07, Endre Stølsvik <[EMAIL PROTECTED]> 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
> http://cwiki.apache.org/ACTIVEMQ/xml-reference.html 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 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.
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?
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
http://activemq.apache.org/camel/contributing.html
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!
Kind regards,
Endre.
