Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (herse.apache.org: domain of james.strachan@gmail.com
 designates 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=L4VNfBSJzAd5ve4NidDJGnCNhaPwFoePteVb0eCGKpGi4pE4v5bNYYfw7h1PPuo3SaMPqoBoAZIJf20D3ABSACSVtmIXTQYNlAQYshZnN9PYoMRl5YyfMRpAi3LX5L2VTd+N4dHDkk4yyjq0iFjc2tMtQH7eXhEhANzABtqpqxQ=
Message-ID: <ec6e67fd0706140653i67f7f7f3kbb6e4be624ac46f1@mail.gmail.com>
Date: Thu, 14 Jun 2007 14:53:48 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: dev@activemq.apache.org
Subject: Re: Handling XSDs and Spring 2 XML processing etc.
In-Reply-To: <46713A68.300@Stolsvik.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <ec6e67fd0706140517s4ba7576eg6e34386da44b0b18@mail.gmail.com>
	 <46713A68.300@Stolsvik.com>

On 6/14/07, Endre St=F8lsvik <Apache@stolsvik.com> 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.

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=3D".." value=3D"..." from Spring with the ActiveMQ
XSDs...


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

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

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.


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

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

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