hi kieth, the challenge here is I am using a third party client which uses castor. The objectfactory uses the static unmarshal() method. Although I could rewrite the objectfactory I don't want to take the responsibility for the third party client. I submitted a patch, which should have minimal impact.
http://bugzilla.exolab.org/show_bug.cgi?id=1868 peter On Wed, 02 Feb 2005 19:35:18 -0600, Keith Visco <[EMAIL PROTECTED]> wrote: > > Peter, > > The static unmarshal() methods are simply for convenience. > > You can easily construct an Unmarshaller, configure it, and invoke it as > such: > > Unmarshaller unm = new Umarshaller(MyClass.class); > unm.setIgnoreExtraElements(true); > unm.unmarshal(myReader); > > --Keith > > Peter Lin wrote: > > has anyone given thought to making strictelement configurable through > > system properties? The reason I ask is, for production I would like > > the ability to turn off strictelements so that in the event a third > > party changes the schema, the server doesn't just get errors. > > > > I was looking over UnmarshalHanlder and the generated java classes are > > using: > > > > public static Object unmarshal(Class c, Reader r) > > > > I was thinking of enhancing the method to check for system properties. > > this way, I can set the system property in production so it's not > > strict. But for development I can set it to strict and catch > > errors/changes in the schema. > > > > peter lin > > > > > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
