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.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name="addressBook">
<xs:complexType>
<xs:sequence>
<xs:element ref="contact" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="email" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The sample XML with nodes added manually.
<addressBook>
<!-- list of contacts -->
<contact>
<name>John Doe</name>
<email>[EMAIL PROTECTED]</email>
<second_email>[EMAIL PROTECTED]</second_email>
</contact>
<contact>
<name>Jane Smith</name>
<email>[EMAIL PROTECTED]</email>
<second_email>[EMAIL PROTECTED]</second_email>
</contact>
<!-- more extra records -->
<contact>
<name>Bob Cole</name>
<email>[EMAIL PROTECTED]</email>
<second_email>[EMAIL PROTECTED]</second_email>
<second_email>[EMAIL PROTECTED]</second_email>
</contact>
</addressBook>
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 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
----------------------------------------------------------- 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
