[castor-user] On the general subject of Castor upgrades: 0.9.7, 0.9.9, and you.

0.9.7 wasn't incompatible for me. Works for me means just that - and it did. But here's a reciprocal question: How is it that no matter how many release candidates we seem to produce, and no matter how many times we ask users to please try out and file a bug if they find issues with

[castor-user] Marshalling to a zip file

Hi: I was wondering if there is an easy way to marshal an object to a zip or gz file? Often my xml files are quit large and it would be nice to directly make a zip file rather than writing an xml then zipping it. Any help would be appreciated. Thanks mas

[castor-user] castor source generator

Hi We are currently using castor 0.9.5.3 to generate Java source files from XML schema. When I try to upgrade to the latest castor, I found the signature of unmarsha method has been changed. It used to return the specific class type but now it returns java.lang.Object. I am not sure if this

Re: [castor-user] castor source generator

Hi Bill, I have run in to this too. Specifically, I have seen this when my schema is using stuff from xml.xsd and xlink.xsd. An example is xml:lang and xlink:href. I think it might be a bug - it is certainly a change in behaviour - but haven't had time to investigate it nor file a bug report

Re: [castor-user] castor source generator

Hi Bill, I have run in to this too. Specifically, I have seen this when my schema is using stuff from xml.xsd and xlink.xsd. An example is xml:lang and xlink:href. I think it might be a bug - it is certainly a change in behaviour - but haven't had time to investigate it nor file a bug report

RE: [castor-user] Marshalling to a zip file

Not crazy at all. I'm using a ZipOutputStream to package into a zip a load of Castor marshalled xml objects styled with xslt for a servlet to return, all without physically creating a file on disk. You might find that you need to add ZipEntry(s) to a ZipOutputStream for each 'file'.

Re: [castor-user] JDO: 1:M problem

You are going to run into problems if you simply replace the whole list. If you can, try and simply add and remove straight from the list itself. I usually always have add/remove methods in my objects that have 1:M relations in them to help this. Castor keeps track of the dependent objects back in

Re: [castor-user] [XML] Validate against XSD when unmarshalling

Invoke foo.validate()? [EMAIL PROTECTED] wrote: Hi, I'd like to validate the XML Message i recieve against the XSD the Data Model was generated from. Let's say i have the following code: Foo foo = Unmarshaller.unmarshall(Foo.class, aReader); The Foo class was generated using the

RE: [castor-user] [XML] Validate against XSD when unmarshalling

Which doesn't validate against the xsd, does it? It'll validate against the descriptor files. Is there a way to validate against the xsd (as a file)? -Original Message- From: Bill Leng [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 22. Juni 2005 17:05 To: user@castor.codehaus.org Subject:

Re: [castor-user] [XML] Validate against XSD when unmarshalling

try foo.setXXX(someInvalidValue); foo.validate(); and see what happens [EMAIL PROTECTED] wrote: Which doesn't validate against the xsd, does it? It'll validate against the descriptor files. Is there a way to validate against the xsd (as a file)? -Original Message- From: Bill Leng

Re: [castor-user] On the general subject of Castor upgrades: 0.9.7, 0.9.9, and you.

Hi Gregory, Gregory Block schrieb: 0.9.7 wasn't incompatible for me. Works for me means just that - and it did. Ok, nice to hear. But here's a reciprocal question: How is it that no matter how many release candidates we seem to produce, and no matter how many times we ask users to please

[castor-user] Marshalling a field which is defined as optional, results in exception

I am using Castor 0.9.6 and marshalling an object which contains an optional field (Email). At certain times this field can be null which is reflected in the xml schema (.xsd, shown below). I am getting the following error during marshalling: java.lang.IllegalStateException: Field access error:

RE: [castor-user] [XML] Validate against XSD when unmarshalling

Hi Simon We do this to, as our xsd performs validation that can't (as far as I know) be done in Castor such as ID/IDREF etc. We keep the xsd in a jar with the rest of the app which makes it easier to find. All you need to do then is create an EntityResolver which locates the xsd file for xerces

Re: [castor-user] How to Map this

Kumar- I used this reference: http://castor.codehaus.org/xml-mapping.html to generate the following mapping file: ?xml version=1.0? !DOCTYPE ... (omitted) ... mapping class name=castor.mettu.SLIR map-to xml=slir / field name=msids type=castor.mettu.MSID

[castor-user] MySQL oddity

Ok, found an odd one here. Nothing to do with Castor, but I think it should be known. I'm using mysql 4.1.11 on my laptop here for dev purposes, and there seems to be a problem with the reported fields coming back from mysql. In SQLEngine around line 963 (the for loop) I get the following

Re: [castor-user] castor source generator

Bill, Nick, Can you please provide us with a short sample XML Schema instance that highlights the problem ? Werner Bill Leng wrote: It looks to me that it is a bug because if you want a java.lang.Object you don't need to cast and no code change is needed. This change breaks the

Re: [castor-user] castor source generator

Bill, The change was due to a bug fix for complexType inheritence in which the unmarshal() method signature cannot be overridden when extending a class. The easiest fix was to simply default to java.lang.Object. I checked in a patch that searches for the proper base type if the class extends