Thanks Ralf... We use CVS here as well. I have built a jar with the modifications in it for our use now. Since there is a new release coming out this week, I will wait for that one.... But I will keep it in mind in the future that I should always try the lastest out of CVS when finding a problem.
Looking through the castor code was not a bad thing though... I learned a lot about how Castor is structured and will be able to better use it's features. Thanks for your help... Barbara -----Original Message----- From: Ralf Joachim [mailto:[EMAIL PROTECTED] Sent: Sunday, March 05, 2006 1:54 PM To: [email protected] Subject: Re: [castor-user] mapping and binding Hi Barbara, the CVS (Concurrent Version System) is an repository to coordinate distributed software developement. While milestones or final releases are only been published from time to time, CVS always contains the most up to date source code. The source code in CVS contains about 33 enhancements or bug fixes to 1.0M2. For an overview of what have been fixed since 1.0M2 you may take a look at: http://jira.codehaus.org/browse/CASTOR?report=com.atlassian.jira.plugin. system.project:roadmap-panel A new milestone build (1.0M3) will be released during next week. There are also various options for you to get the latest source for CVS described at: http://castor.codehaus.org/cvs.html As the behaviour of castor for the problem you are facing changed according to my tests, you definitly should pull the latest code from CVS. Be aware that CVS only contains source and required libs but not the castor.jar. You will need to build this yourself using ant. A new download of the 1.0M2 release will not include bespoken changes. Having said that I always get a copy of any comments to an issue in jira as I'm one of the committers. In addition to the committers, the reporter, the assignee and anyone watching a particular issue gets notified on its changes. Therefore it is not neccessary to announce them on users mailing list for me ;-) If you like to keep other users informed you are still open to do so. Regards Ralf Barbara Prechtl schrieb: > Ralf: > > I see that you added a note to the issue that I created > http://jira.codehaus.org/browse/CASTOR-1340 . I was wondering why castor version 1.0M2 worked for you. You said you got it out of CVS, it the CVS the working version of M2 that will go into M3? Not sure. Just would like to get a copy of the jar as well. > > BTW... I did spend a little time debugging the problem also... found > the line that was causing the problem. Thanks for your help. Let me > know how I go about getting the copy of the jar that you worked > with.... should I pull the code from CVS or should I download a new > version of the 1.0M2 released jar? > > Thanks again... > > Barbara > > > -----Original Message----- > From: Prechtl, Barbara [VMMH:RP21:EXCH] > Sent: Friday, March 03, 2006 10:54 PM > To: [email protected] > Cc: Levine, Jacob [VMMH:RP21:EXCH]; Caritos, Eladio [VMMH:RP13:EXCH] > Subject: RE: [castor-user] mapping and binding > > > Ralf: > > I have created a simple example of the problem and attached it to > issue http://jira.codehaus.org/browse/CASTOR-1340 . In this issue you > will see that the code generator is incorrectly creating the > newInstance method: > > public java.lang.Object newInstance( java.lang.Object parent ) { > return null; > } > Should be changed to generate > > public java.lang.Object newInstance( java.lang.Object parent ) { > return new com.schema.code.shared.DescriptionGroup(); > } > This makes the unmarshaller work. > > I also added issue http://jira.codehaus.org/browse/CASTOR-1339 where > there is a missing check for a null object before using it. This > causes a problem related to using the MappingTool that I was trying to > use to generate the map files. When I added the check to the code (I > pulled in the castor source and jared it up myself) the mapping tool > worked. > > I would be most interested in having a fix for the 1340 issue.... even > if you can give me the temporary patched classes. I really need to > have this issue fixed, as I have many groups in my current schema. > > Thanks, > > Barbara > > > -----Original Message----- > From: Stephen Bash [mailto:[EMAIL PROTECTED] > Sent: Friday, March 03, 2006 3:39 PM > To: [email protected] > Subject: Re: [castor-user] mapping and binding > > Ralf- > > Just to throw in my $0.02 (I know, not worth as much as it used to), > if the Java objects created store the information correctly, than it > might be possible to remove the generated descriptors from the > classpath and use a simple mapping file. But without digging into an > example (and as I've said before, knowing very little about the > SourceGenerator) I don't know how complicated this would be. If the > "not using groups" option is quicker/easier, I'm all for it. > > Thanks for the help, > Stephen > > > On 3/3/06, Ralf Joachim <[EMAIL PROTECTED]> wrote: > >>Hi Barbara, >> >>if you create the new jira issue and attach a simple test case i'll >>try to debug myself in about an hour. If you could join >>irc://irc.codehaus.org/castor at that time it may reduce time to find >>a solution if there is one ;-) >> >>Regards >>Ralf >> >> >>Barbara Prechtl schrieb: >> >>>To whom it may concern: >>> >>>NullPointerException: >>> at >>>org.exolab.castor.xml.Marshaller.processAttribute(Marshaller.java:232 0) >>> at >>>org.exolab.castor.xml.Marshaller.marshal(Marshaller.java:1323) >>> at >>>org.exolab.castor.xml.Marshaller.marshal(Marshaller.java:1824) >>> at org.exolab.castor.xml.Marshaller.marshal(Marshaller.java:821) >>> at >>>org.exolab.castor.tools.MappingTool.write(MappingTool.java:478) >>> at >>>com.nortel.sce.Map.MappingCreator.createMap(MappingCreator.java:68) >>> at >>>com.nortel.sce.Map.CreateClassMaps.createMappingFiles(CreateClassMaps >>>.ja >>>va:46) >>> at >>>com.nortel.sce.Map.CreateClassMaps.main(CreateClassMaps.java:88) >>> >>>In processAttribute method of Marshaller.java there is code that does >>>the following. Please notice the use of value. Value is null after >>>the first call to get value in the first try. The first if cause >>>value is null is surpassed, the else goes on and uses value which >>>causes a null pointer exception. >>> >>>I noticed this when using the mapping tool. >>> >>> Object value = null; >>> >>> try { >>> value = attDescriptor.getHandler().getValue(object); >>> } >>> catch(IllegalStateException ise) { >>> return; >>> } >>> //-- handle IDREF(S) >>> if (attDescriptor.isReference() && (value != null)) { >>> >>> if (attDescriptor.isMultivalued()) { >>> Enumeration enumeration = null; >>> if (value instanceof Enumeration) { >>> enumeration = (Enumeration)value; >>> } >>> else { >>> CollectionHandler colHandler = null; >>> try { >>> colHandler = >>>CollectionHandlers.getHandler(value.getClass()); >>> } >>> catch(MappingException mx) { >>> throw new MarshalException(mx); >>> } >>> enumeration = colHandler.elements(value); >>> } >>> if (enumeration.hasMoreElements()) { >>> StringBuffer sb = new StringBuffer(); >>> for (int v = 0; enumeration.hasMoreElements(); >>>v++) { >>> if (v > 0) sb.append(' '); >>> >>>sb.append(getObjectID(enumeration.nextElement()).toString()); >>> } >>> value = sb; >>> } >>> else value = null; >>> } >>> else { >>> value = getObjectID(value); >>> } >>> } >>> //-- handle multi-value attributes >>> else if (attDescriptor.isMultivalued()) { >>> Enumeration enumeration = null; >>> if (value instanceof Enumeration) { >>> enumeration = (Enumeration)value; >>> } >>> else { >>> CollectionHandler colHandler = null; >>> try { >>> colHandler = >>>CollectionHandlers.getHandler(value.getClass()); >>> } >>> catch(MappingException mx) { >>> throw new MarshalException(mx); >>> } >>> enumeration = colHandler.elements(value); >>> } >>> if (enumeration.hasMoreElements()) { >>> StringBuffer sb = new StringBuffer(); >>> for (int v = 0; enumeration.hasMoreElements(); v++) { >>> if (v > 0) sb.append(' '); >>> sb.append(enumeration.nextElement()).toString(); >>> } >>> value = sb; >>> } >>> else value = null; >>> } >>> else if (value != null) { >>> >>>-----Original Message----- >>>From: Stephen Bash [mailto:[EMAIL PROTECTED] >>>Sent: Friday, March 03, 2006 1:08 PM >>>To: [email protected] >>>Subject: Re: [castor-user] mapping and binding >>> >>>Barbara- >>> >>>I came to the same conclusion about the NPE. Because you are using >>>the SourceGenerator, the descriptors referenced in the code snippet >>>you quoted are actually Java code that you can open up and look at, >>>which may or may not be helpful. >>> >>>What you're actually interested in is the FieldDescriptor, but you >>>might be able to find that based on the ClassDescriptor (just follow >>>the method calls) -- I think Castor names the classes in a fairly >>>obvious way, so something like NodeTypeClassDescriptor or >>>DescriptionGroupFieldDescriptor would be a good place to start >>>looking. If you open the FieldDescriptor (whatever it ends up being >>>named) and check what its getFieldType method is doing, that might >>>give some hint to what is happening. Unfortunately we're rapidly >>>crossing into code I know nothing about... If getFieldType simply >>>returns null, that comes from the SourceGenerator, and I'm not much >>>help telling you why it wrote that, but maybe someone else can. >>> >>>Let me know what you find. >>> >>>Stephen >>> >>> >>>On 3/3/06, Barbara Prechtl <[EMAIL PROTECTED]> wrote: >>> >>> >>>>Stephen: >>>> >>>>I tried the generateImportedSchema to true and it still did not >>>>work. >>> >>>I >>> >>> >>>>sent you the place in the unmarshaller where it is failing. Please >>>>let me know if you still want me to put together an example.... >>>>cause I will, I just have lots of other unrelated stuff in the >>>>schema that is not necessary to send. >>>> >>>>Barbara >>>> >>>>-----Original Message----- >>>>From: Stephen Bash [mailto:[EMAIL PROTECTED] >>>>Sent: Friday, March 03, 2006 12:39 PM >>>>To: [email protected] >>>>Subject: Re: [castor-user] mapping and binding >>>> >>>>Barbara- >>>> >>>>What version of Castor are you using? I don't know much about the >>>>SourceGeneration side, but with the correct version of Castor I >>>>might be able to look at the stack trace and figure out what is >>>>happening. Next question, can you produce the XML snippet you >>>>mentioned from marshalling? I'll try to look into it and see if I >>>>can glean any information from the stack trace. >>>> >>>>Stephen >>>> >>>> >>>>On 3/3/06, Barbara Prechtl <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>>Stephan: >>>>> >>>>>Thanks for your help. I did get the Java objects to marshall >>>>>without >>>> >>>>the >>>> >>>> >>>>>use of a mapping file. >>>>> >>>>>I am now having problems with the unmarshalling of documents that >>> >>>use >>> >>> >>>>>elements that are of a group type. For instance I have defined in >>>>>my schema a description group as follows: >>>>> >>>>> <xsd:group name="DescriptionGroup"> >>>>> <xsd:sequence> >>>>> <xsd:element name="description" >>>>>type="xsd:string" minOccurs="0" maxOccurs="1"/> >>>>> </xsd:sequence> >>>>> </xsd:group> >>>>> >>>>>This is used in my NodeType definition: >>>>> >>>>><xsd:complexType name="NodeType"> >>>>> <xsd:sequence> >>>>> <xsd:group >>>>>ref="shr:DescriptionGroup"></xsd:group> >>>>> </xsd:sequence> >>>>></xsd:complexType> >>>>> >>>>> >>>>>When in my instance document I have the description the >>> >>>unmarshalling >>> >>> >>>>>throws an exception. >>>>> >>>>><node> >>>>> <description> comment </description> >>>>></node> >>>>> >>>>>When I create the classes with the source generator I use the >>>> >>>>following >>>> >>>> >>>>>flags: >>>>> >>>>>generateMappingFiles=true >>>>>createMarshalMethods=true >>>>>GenerateImportedSchemas=false >>>>>Validation=true >>>>> >>>>>I am getting an error every time I try to use the description >>> >>>element >>> >>> >>>>in >>>> >>>> >>>>>a document. I have noticed that this happens with other group >>>>>types. Does group unmarshalling work? >>>>> >>>>>Thanks, >>>>>Barbara >>>>> >>>>>The error I get is as follows: >>>>> >>>>>Error occurred in read. Target Exception is:: >>>>>org.exolab.castor.xml.MarshalException : null >>>>>null{file: [not available]; line: 64; column: 18} >>>>> at >>>>>org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:669) >>>>> at >>>>>org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:563) >>>>> at >>>>> >>>> >>>com.nortel.sce.xml.utils.XmlToJava.readXMLinstanceToObject(XmlToJava. >>>jav >>> >>> >>>>>a:143) >>>>> at >>>>>com.nortel.sce.xml.utils.XmlUtils.unmarshallXML(XmlUtils.java:89) >>>>> at >>>>>com.nortel.sce.model.ContainerData.read(ContainerData.java:109) >>>>> at >>>>>com.nortel.sce.model.ContainerData.<init>(ContainerData.java:52) >>>>> at >>>>> >>>> >>>com.nortel.sce.model.ApplicationData.getContainerByName(ApplicationDa >>>ta. >>> >>> >>>>>java:135) >>>>> at com.nortel.sce.model.ModelData.main(ModelData.java:273) >>>>>Caused by: java.lang.NullPointerException >>>>> at >>>>> >>>> >>>org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler. >>>jav >>> >>> >>>>>a:1994) >>>>> at >>>>> >>>> >>>org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler. >>>jav >>> >>> >>>>>a:1375) >>>>> at >>>>> >>> >>>org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376) >>> >>> >>>>> at >>>>> >>>> >>>org.apache.xerces.validators.common.XMLValidator.callStartElement(XML >>>Val >>> >>> >>>>>idator.java:1214) >>>>> at >>>>> >>>> >>>org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.disp >>>atc >>> >>> >>>>>h(XMLDocumentScanner.java:1171) >>>>> at >>>>> >>>> >>>org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentS >>>can >>> >>> >>>>>ner.java:381) >>>>> at >>>>>org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) >>>>> at >>>>>org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:655) >>>>> >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Stephen Bash [mailto:[EMAIL PROTECTED] >>>>>Sent: Friday, March 03, 2006 8:30 AM >>>>>To: [email protected] >>>>>Subject: Re: [castor-user] mapping and binding >>>>> >>>>>Barbara- >>>>> >>>>>I'm not much of an expert on the binding-file side, but I use >>> >>>mapping >>> >>> >>>>>files all the time. The short answer is no, you don't need both, >>> >>>but >>> >>> >>>>>yes, they both describe Java object <-> XML relations. >>>>> >>>>>In general, I believe, the binding file is used to create Java code >>>>>(that can then be compiled and used in an application) from an XML >>>>>Schema. The binding file is most often (only?) used with the >>>>>Castor SourceGenerator, which creates Java classes that model an >>>>>XML >>> >>>schema, >>> >>> >>>>>at which point Castor also creates extra classes (ClassDescriptors >>> >>>and >>> >>> >>>>>FieldDescriptors) that describe how the Java objects "map" to XML. >>>>> >>>>>The mapping file provides an alternate method for the user to >>> >>>specify >>> >>> >>>>>how Java objects transform into XML content. I tend to think of >>> >>>this >>> >>> >>>>>as how one starts with a Java object model and then creates the XML >>>>>structure from it, but it is much more flexible than that. >>>>> >>>>>Where the two methods somewhat meet is the >>>>>ClassDescriptor/FieldDescriptor level. When a user loads a >>>>>mapping, Castor reads the mapping file and internally creates the >>>>>appropriate descriptors. If the SourceGenerator was used, the >>>>>descriptors exist as compiled classes and are instantiated as they >>>>>are needed (thus >>> >>>the >>> >>> >>>>>mapping file usually isn't required). >>>>> >>>>>That might be more information than you needed, but hopefully it >>>>>answers the question. Let us know if you have further questions. >>>>> >>>>>Stephen >>>>> >>>>>On 3/3/06, Barbara Prechtl <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>> >>>>>>To whom it may concern: >>>>>> >>>>>> >>>>>> >>>>>>I was wondering what the difference between a mapping file and a >>>>> >>>>>binding >>>>> >>>>> >>>>>>file is. >>>>>> >>>>>> >>>>>> >>>>>>Is this correct: >>>>>> >>>>>> >>>>>> >>>>>>A mapping file is used for writing java objects to xml. >>>>>> >>>>>>A binding file is used to read xml to java objects. >>>>>> >>>>>> >>>>>> >>>>>>They both seem to describe the element to object relation. Are >>> >>>both >>> >>> >>>>>needed? >>>>> >>>>> >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Barbara >>>>> >>>>>------------------------------------------------- >>>>>If you wish to unsubscribe from this list, please >>>>>send an empty message to the following address: >>>>> >>>>>[EMAIL PROTECTED] >>>>>------------------------------------------------- >>>>> >>>>> >>>> >>>>------------------------------------------------- >>>>If you wish to unsubscribe from this list, please >>>>send an empty message to the following address: >>>> >>>>[EMAIL PROTECTED] >>>>------------------------------------------------- >>>> >>>> >>> >>> >>>------------------------------------------------- >>>If you wish to unsubscribe from this list, please >>>send an empty message to the following address: >>> >>>[EMAIL PROTECTED] >>>------------------------------------------------- >> >>-- >> >>Syscon Ingenieurb ro f r >>Me - und Datentechnik GmbH >>Ralf Joachim >>Raiffeisenstra e 11 >>D-72127 Kusterdingen >>Germany >> >>Tel. +49 7071 3690 52 >>Mobil: +49 173 9630135 >>Fax +49 7071 3690 98 >> >>Email: [EMAIL PROTECTED] >>Web: www.syscon-world.de >> >>------------------------------------------------- >>If you wish to unsubscribe from this list, please >>send an empty message to the following address: >> >>[EMAIL PROTECTED] >>------------------------------------------------- >> >> > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
