Re: [castor-dev] question on strictelements
Hi Peter, Yikes, I guess I need to supply a LocalConfiguration#setProperties() method that can be called to indicate property changes. Unfortunately once the LocalConfiguration is created the properties are currently written in stone. I wasn't aware of that limitation. The good news is that you can work around that by setting the global defaults with a simple change to your code (the following will work! :-) Properties props = Configuration.getDefault(); props.setProperty(Configuration.Property.StrictElements,"false"); So basically don't use the LocalConfiguration class. --Keith Peter Lin wrote: Hi keith, I tried your suggestion, but it doesn't appear to work. I'm using 0.9.5. I generated classes using the following sample schema from JWSDP. http://www.w3.org/2001/XMLSchema";> The sample XML with nodes added manually. John Doe [EMAIL PROTECTED] [EMAIL PROTECTED] Jane Smith [EMAIL PROTECTED] [EMAIL PROTECTED] Bob Cole [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I wrote a simple test class to see if using the LocalConfiguration works, but it doesn't appear to work as I expected. Am I doing something wrong? Here is my simple test class. package test; import java.io.FileReader; import java.util.Properties; import org.exolab.castor.xml.Unmarshaller; import org.exolab.castor.util.*; public class ConfigTest { public ConfigTest(){ } public static void main(String[] args) { try { Properties props = LocalConfiguration.getInstance().getProperties(); props.setProperty(Configuration.Property.StrictElements,"false"); String in = "contact_2.xml"; FileReader reader = new FileReader(in); AddressBook abook = (AddressBook)Unmarshaller.unmarshal(test.AddressBook.class, reader); if (abook != null){ System.out.println("email=" + abook.getContact(0).getEmail()); System.out.println("name=" + abook.getContact(0).getName()); } else { System.out.println("it failed"); } } catch (Exception e){ e.printStackTrace(); } } } any help is greatly appreciated. If there's another way set StrictElements to off and still use object.unmarshal() static method that would be great. peter lin On Fri, 04 Feb 2005 18:12:50 -0600, Keith Visco <[EMAIL PROTECTED]> wrote: Hi Peter, Have you tried the following: import org.exolab.castor.util.Configuration; import org.exolab.castor.util.LocalConfiguration; Properties props = LocalConfiguration.getInstance().getProperties(); props.setProperty(Configuration.Property.StrictElements, "true"); Just be careful when setting global castor properties, especially if multiple apps running in the same VM are using Castor. Changing static properties on one instance will change the same value for all instances running in the same VM. --Keith Peter Lin wrote: What are the chances of my patch getting into the next release? http://bugzilla.exolab.org/show_bug.cgi?id=1868 I totally understand the static unmarshal() methods are there for convenience, which is probably why the third party client I'm using is using them :) I imagine other people are also using it out of convienance. I test the patch and it does make it easier for someone to set -D and disable StrictElements. I can think of several reasons why the feature is useful. 1. if someone needs to debug an issue in production (which is aweful to do), they can simply set -D and see if it fixes the problem. If it does, the developer knows the problem is extra elements. 2. it allows users exclude the -D property in development and staging, but turn StrictElements off for production without having to change the properties file. Although one could change their deployment so it extracts the castor jar, modifies the properties file and re-jars it. 3. for projects with complex deployment process on an EJB server, not having to extract and modify a jar is nice. I guess one could have 1 jar for dev and staging and a second for production. I'm not sure I like the idea of having two jar files. obviously, I can make my own build, but I'm hoping others find the enhancement useful enough to include. thanks 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
Re: [castor-dev] question on strictelements
Hi keith, I tried your suggestion, but it doesn't appear to work. I'm using 0.9.5. I generated classes using the following sample schema from JWSDP. http://www.w3.org/2001/XMLSchema";> The sample XML with nodes added manually. John Doe [EMAIL PROTECTED] [EMAIL PROTECTED] Jane Smith [EMAIL PROTECTED] [EMAIL PROTECTED] Bob Cole [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I wrote a simple test class to see if using the LocalConfiguration works, but it doesn't appear to work as I expected. Am I doing something wrong? Here is my simple test class. package test; import java.io.FileReader; import java.util.Properties; import org.exolab.castor.xml.Unmarshaller; import org.exolab.castor.util.*; public class ConfigTest { public ConfigTest(){ } public static void main(String[] args) { try { Properties props = LocalConfiguration.getInstance().getProperties(); props.setProperty(Configuration.Property.StrictElements,"false"); String in = "contact_2.xml"; FileReader reader = new FileReader(in); AddressBook abook = (AddressBook)Unmarshaller.unmarshal(test.AddressBook.class, reader); if (abook != null){ System.out.println("email=" + abook.getContact(0).getEmail()); System.out.println("name=" + abook.getContact(0).getName()); } else { System.out.println("it failed"); } } catch (Exception e){ e.printStackTrace(); } } } any help is greatly appreciated. If there's another way set StrictElements to off and still use object.unmarshal() static method that would be great. peter lin On Fri, 04 Feb 2005 18:12:50 -0600, Keith Visco <[EMAIL PROTECTED]> wrote: > > > Hi Peter, > > Have you tried the following: > > import org.exolab.castor.util.Configuration; > import org.exolab.castor.util.LocalConfiguration; > > Properties props = LocalConfiguration.getInstance().getProperties(); > props.setProperty(Configuration.Property.StrictElements, "true"); > > Just be careful when setting global castor properties, especially if > multiple apps running in the same VM are using Castor. Changing static > properties on one instance will change the same value for all instances > running in the same VM. > > --Keith > > > Peter Lin wrote: > > What are the chances of my patch getting into the next release? > > > > http://bugzilla.exolab.org/show_bug.cgi?id=1868 > > > > I totally understand the static unmarshal() methods are there for > > convenience, which is probably why the third party client I'm using is > > using them :) I imagine other people are also using it out of > > convienance. > > > > I test the patch and it does make it easier for someone to set -D and > > disable StrictElements. I can think of several reasons why the feature > > is useful. > > > > 1. if someone needs to debug an issue in production (which is aweful > > to do), they can simply set -D and see if it fixes the problem. If it > > does, the developer knows the problem is extra elements. > > > > 2. it allows users exclude the -D property in development and staging, > > but turn StrictElements off for production without having to change > > the properties file. Although one could change their deployment so it > > extracts the castor jar, modifies the properties file and re-jars it. > > > > 3. for projects with complex deployment process on an EJB server, not > > having to extract and modify a jar is nice. I guess one could have 1 > > jar for dev and staging and a second for production. I'm not sure I > > like the idea of having two jar files. > > > > obviously, I can make my own build, but I'm hoping others find the > > enhancement useful enough to include. thanks > > > > 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
Re: [castor-dev] question on strictelements
thanks for the suggestion, i'll give it a try. should be a workable solution. peter On Fri, 04 Feb 2005 18:12:50 -0600, Keith Visco <[EMAIL PROTECTED]> wrote: > > > Hi Peter, > > Have you tried the following: > > import org.exolab.castor.util.Configuration; > import org.exolab.castor.util.LocalConfiguration; > > Properties props = LocalConfiguration.getInstance().getProperties(); > props.setProperty(Configuration.Property.StrictElements, "true"); > > Just be careful when setting global castor properties, especially if > multiple apps running in the same VM are using Castor. Changing static > properties on one instance will change the same value for all instances > running in the same VM. > > --Keith --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] question on strictelements
Hi Peter, Have you tried the following: import org.exolab.castor.util.Configuration; import org.exolab.castor.util.LocalConfiguration; Properties props = LocalConfiguration.getInstance().getProperties(); props.setProperty(Configuration.Property.StrictElements, "true"); Just be careful when setting global castor properties, especially if multiple apps running in the same VM are using Castor. Changing static properties on one instance will change the same value for all instances running in the same VM. --Keith Peter Lin wrote: What are the chances of my patch getting into the next release? http://bugzilla.exolab.org/show_bug.cgi?id=1868 I totally understand the static unmarshal() methods are there for convenience, which is probably why the third party client I'm using is using them :) I imagine other people are also using it out of convienance. I test the patch and it does make it easier for someone to set -D and disable StrictElements. I can think of several reasons why the feature is useful. 1. if someone needs to debug an issue in production (which is aweful to do), they can simply set -D and see if it fixes the problem. If it does, the developer knows the problem is extra elements. 2. it allows users exclude the -D property in development and staging, but turn StrictElements off for production without having to change the properties file. Although one could change their deployment so it extracts the castor jar, modifies the properties file and re-jars it. 3. for projects with complex deployment process on an EJB server, not having to extract and modify a jar is nice. I guess one could have 1 jar for dev and staging and a second for production. I'm not sure I like the idea of having two jar files. obviously, I can make my own build, but I'm hoping others find the enhancement useful enough to include. thanks 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 --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] question on strictelements
What are the chances of my patch getting into the next release? http://bugzilla.exolab.org/show_bug.cgi?id=1868 I totally understand the static unmarshal() methods are there for convenience, which is probably why the third party client I'm using is using them :) I imagine other people are also using it out of convienance. I test the patch and it does make it easier for someone to set -D and disable StrictElements. I can think of several reasons why the feature is useful. 1. if someone needs to debug an issue in production (which is aweful to do), they can simply set -D and see if it fixes the problem. If it does, the developer knows the problem is extra elements. 2. it allows users exclude the -D property in development and staging, but turn StrictElements off for production without having to change the properties file. Although one could change their deployment so it extracts the castor jar, modifies the properties file and re-jars it. 3. for projects with complex deployment process on an EJB server, not having to extract and modify a jar is nice. I guess one could have 1 jar for dev and staging and a second for production. I'm not sure I like the idea of having two jar files. obviously, I can make my own build, but I'm hoping others find the enhancement useful enough to include. thanks 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
Re: [castor-dev] question on strictelements
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
Re: [castor-dev] question on strictelements
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