Ralf:

Not sure if you get any information on notes added to closed issues...
The issue below is still an issue with the latest code from CVS. I
stepped through the code and found the error. I was not sure how to
reopen the issue. I added a note to it explaining where the error is.
Could you set the issue to the open state?

Also I found another error that I have to create a patch for as well...
I could add both of these together ... I still need to read on the
patching mechanism that castor uses... Cause I am not in the development
pool. 

Thanks...
Barbara


-----Original Message-----
From: Prechtl, Barbara [VMMH:RP21:EXCH] 
Sent: Saturday, March 04, 2006 10:01 PM
To: [email protected]
Subject: RE: [castor-user] mapping and binding


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:2320)
> >       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(CreateClassMap
> > s.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(ApplicationD
> > ata.
> >
> >>>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(XM
> > LVal
> >
> >>>idator.java:1214)
> >>>        at
> >>>
> >>
> > org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dis
> > patc
> >
> >>>h(XMLDocumentScanner.java:1171)
> >>>        at
> >>>
> >>
> > org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocument
> > Scan
> >
> >>>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]
-------------------------------------------------

Reply via email to