David Jencks wrote:
Offhand I don't see why this is better than spring + xbean-spring, where you get an xsd generated from your classes that your server.xml plan can be validated against. Furthermore you don't have to write the code that translates from the xmlbeans objects to the runtime components, as spring does that part for you. Could you explain?
The requirements (in my mind anyway) are that it must be simple, it must be difficult to get wrong, it must be simple to change, and errors must be clear and simple enough to understand for a sleep deprived sysadmin at 3am. In my experience, traditional XML based Spring fails on all these counts.
At the core, if the user puts something syntactically invalid into their config file, they must get a reasonable error message telling them exactly what went wrong. Getting a general Spring error means nothing whatsoever to an end user.
That's not to say that xbean-spring won't fit the bill, as long as it fits the requirements above.
However if anyone decides to go in this direction I think that using jaxb instead of xmlbeans, and more particularly sxc, is definitely the way to go. I think there's a good chance that it would be easy to make the runtime components actually be the jaxb objects.
From the sxc page at http://sxc.codehaus.org/JAXB: "What is not implemented? [snip] Validation".Lack of validation to me is a showstopper - if there is a syntax error or omission in a config file, and the resulting error message is either incomprehensible to the admin or (worse) it fails silently, then it represents some serious breakage.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
