activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Handling XSDs and Spring 2 XML processing etc.
Date Thu, 14 Jun 2007 12:17:55 GMT
There's been various gremlins all over the place in the support of
pure spring XML handling. i.e. rather than using XBean to parse the
XML, using a pure Spring Xml Application Context to parse ActiveMQ
inside any Spring XML.

There's been quite a few JIRAs around this area...

Certainly the most lively has been this one :)

There were numerous issues.

A) Bad XSDs caused by a bug in XBean which is now fixed in 3.x of XBean

B) Lousy URLs for the XSDs. We've now got all the XSDs available at
simpler URLs:

releases of XSDs appear here...

such as

and snapshot schemas appear here

such as

C) Spring was often unable to find the embedded XSD without some
remote URL for the schema location. So the fix for anyone having
spring problems is just to use the new correct XSD.

For example...


(Note that we need a 4.1.2 release with the latest XBean to get a nice
fixed XSD, see

I've updated the XML reference with links to the various XSDs etc

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

(ii) should we update the current namespace URI in 5.0 of ActiveMQ to
reflect both good Spring 2 practice on naming URIs and XSDs, together
with reflecting that we are actually at Apache now :)

The current URI is

it might be better to use

then it'd look more natural in spring docs?



if folks wanna put a version number in?

This would mean breaking backwards compatibility with XML
configuration files; but given its never really worked inside Spring
2.0 properly; and with 5.0 having some different XML defaults anyway -
maybe its not such a big issue?

(iii) Should we consider some kinda alias; such as

meaning 'use the latest version of 5.x you can find'. (Assuming we can
figure out how to that :)

Then if we release 5.1, 5.2, with minor XSD changes, folks get them
for free without changing config files. (Admitedly they'd get that for
free by just using no version in the URL).


View raw message