after sharing an e-mail or two with Earl I realized that I could solve my
problem by adding a mapping for java.util.HashMap, i.e.,
<class name="java.util.HashMap" auto-complete="false"/>
this inhibits the introspection by castor into the HashMap and prevents the
problems in XMLClassDescriptorImpl.
But, I don't really understand why I am having this problem, since I assume
other people are using HashMap valued properties with 0.9.5.3 - either in
the 'old' way (w/o separate key mapping) or the 'new'.
Jay Goldman
-----Original Message-----
From: Jay Goldman
Sent: Tuesday, May 25, 2004 1:59 PM
To: [EMAIL PROTECTED]
Subject: [castor-user] re: "[castor-dev] Null Pointer Exception in
XMLClassDescriptorImpl"
I appear to have run into the problem described in a previous post (see
below) by having a class which contains a hashmap variable. I am trying to
use hibernate 0.9.5.3)
I have set saveMapKeys to false (since I am trying to upgrade with existing
xml files)
I have tried setting 'auto-complete="false"' on all of the <class>
definitions in the mapping file but to no avail - the code mentioned below
winds up with an array of length 1 with a null entry.which causes a null
pointer exception down the road.
so how do I inhibit introspection into the Hashmap class? Do I need to
provide an explicit xml mapping for the HashMap class?
(Null Pointer Exception ...(partial stack trace)
at
org.exolab.castor.xml.util.XMLClassDescriptorImpl.validate(XMLClassDescripto
rImpl.java:890)
at org.exolab.castor.xml.Validator.validate(Validator.java:122)
at
org.exolab.castor.xml.FieldValidator.validate(FieldValidator.java:258)
at
org.exolab.castor.xml.util.XMLClassDescriptorImpl.validate(XMLClassDescripto
rImpl.java:892)
at org.exolab.castor.xml.Validator.validate(Validator.java:122)
at
org.exolab.castor.xml.FieldValidator.validate(FieldValidator.java:258)
at
org.exolab.castor.xml.util.XMLClassDescriptorImpl.validate(XMLClassDescripto
rImpl.java:892)
at org.exolab.castor.xml.Validator.validate(Validator.java:122)
at
org.exolab.castor.xml.FieldValidator.validate(FieldValidator.java:241)
at
org.exolab.castor.xml.util.XMLClassDescriptorImpl.validate(XMLClassDescripto
rImpl.java:892)
at org.exolab.castor.xml.Validator.validate(Validator.java:122)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:843)
at
org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1038
)
some of the mapping file:
<class name="com...Tasks" auto-complete="false">
<field name="loggingDef" type="com...LoggingDef" required="false">
<bind-xml name="logging" node="element"/>
</field>
</class>
<class name="com...LoggingDef" auto-complete="false">
<field name="logFiles" type="com...LogFileDef" collection="map">
<bind-xml name="logFile" node="element">
</field>
</class>
<class name="com...LogFileDef" auto-complete="false">
<field name="displayName" type="string" required="true">
<bind-xml name="displayName" node="attribute"/>
</field>
</class>
Jay Goldman
-----Original Message-----
From: Keith Visco [mailto:[EMAIL PROTECTED]
Subject: Re: [castor-dev] Null Pointer Exception in XMLClassDescriptorImpl
Hi Earl,
Thanks for your interest in Castor and willingness to help fix the
issue
you've run across.
In order for us to better determine if your patch is the proper one,
can
you open a bug report at http://bugzilla.exolab.org and attach your
patch (as a diff file), as well as a small test case which
demonstrates
the problem before the patch is applied.
More information on contributing to Castor can be found here:
http://castor.exolab.org/cvs.html#Guidelines-For-Code-Contribution
<http://castor.exolab.org/cvs.html>
Thanks,
--Keith
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]:%20[castor-dev]%20Null%20Po
inter%20Exception%20in%20XMLClassDescriptorImpl&replyto=407AE64D.3AA7B7C
[EMAIL PROTECTED]> wrote:
>
> I'm a newbie to Castor, and an infrequent Java Programmer, so
please be
> gentle in your response. I'll try to explain the problem that I've
had to
> the best of my abilities. I've made a change to the
XMLClassDescriptorImpl.
> It resolves the problem, but since I have very little idea what
I'm doing,
> I don't know what problems my solution might cause.
>
> The class that I was trying to marshal had 3 levels of
inheritance.
> Apparently, one of the methods (elements) that has been added to
the
> allElements array has been overridden more than once and is in
allElements
> twice. Because it is an inherited method, it is also in the
inherited
> array. The size of localElements is determined by subtracting the
size of
> the inherited array from the size of the allElements array. The
code
> starting at line 776 below causes the localElements array to have
(in this
> case) one null entry as the last entry in the array because the
entry from
> allElements is not written to localElements if it is inherited.
>
> For my quick fix, I simply traversed the localElements array and
rewrote it
> without the null entry. My biggest concern is what problems I may
have
> caused down the road. Marshalling appears to work fine. This is
probably
> because the method in question was not a Getter or a Setter.
>
> Any insights into this problem, or my solution to it, would be
greatly
> appreciated.
>
> localElements = new XMLFieldDescriptor[allElements.length -
> inherited.length];
> int localIdx = 0;
> int localCnt=0;
> int localNewIdx=0;
> 776 for (int i = 0; i < allElements.length; i++) {
> XMLFieldDescriptor desc = allElements[i];
> boolean isInherited = false;
> for (int idx = 0; idx < inherited.length; idx++) {
> if (inherited[idx].equals(desc)) {
> isInherited = true;
> break;
> }
> }
> if (!isInherited) {
> localElements[localIdx] = desc;
> ++localIdx;
> }
> }
> // count non-null entries in localElements
> 790 for (int j = 0; j < localElements.length; j++) {
> if(!(localElements[j]== null)) {
> localCnt++;
> }
>
> }
> // create a new array to replace localElements
> XMLFieldDescriptor[]localElementsNew = new
> XMLFieldDescriptor[localCnt];
> // populate new array with non-null values from localElements
> for (int k = 0; k < localElements.length; k++) {
> if(!(localElements[k]== null)) {
> localElementsNew[localNewIdx] = localElements[k];
> localNewIdx++;
> }
>
> }
> //replace localElements with new array
> 802 localElements = localElementsNew;
>
> Thanks,
>
> Earl Armstrong, CLU, FLMI, ACS, AIAA
> __________________________________
> IS Individual Life Systems Team - 3A-AS
> LIFE-COMM New Business, NextGen
> Protective Life Corporation
> Phone (205)268-2965 Fax (205)268-3474
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
