Hi Nick,
You can ignore my previous reply as I though you were talking about
Castor XML, not Castor JDO.
Castor XML supports the "is" methods, and I believe they are supported
by the default "shared" FieldHandler, but I am not sure if this is also
supported via Castor JDO's special classes (eg. FieldMolder).
I'll have to defer to Bruce on that.
--Keith
Nick Stuart wrote:
>
> The get/set methods make sense. But I'm not having any luck with the
> boolean. Here's an example of what I'm doing...
>
> <class name="com.vort.ads.vortsentry.beans.VortSentryModelDims"
> identity="id"
> depends="com.vort.ads.vortsentry.beans.VortSentryDims"
> key-generator="IDENTITY">
> .....
> <field name="combineBaseSlabRiser" type="boolean">
> <sql name="combineBaseSlabRiser" type="char[01]"/>
> </field>
> </class>
>
> public class VortSentryModelDims implements Serializable,
> TimeStampable, Cloneable {
> ....
> private boolean combineBaseSlabRiser;
> ....
> public boolean isCombineBaseSlabRiser() {
> return combineBaseSlabRiser;
> }
>
> public void setCombineBaseSlabRiser(boolean combineBaseSlabRiser) {
> this.combineBaseSlabRiser=combineBaseSlabRiser;
> }
> }
>
> With the above mapping/class I get the following exception:
> org.exolab.castor.mapping.MappingException: The method
> getcombineBaseSlabRiser in class
> com.vort.ads.vortsentry.beans.VortSentryModelDims accepting/returning
> object of type null was not found
> at
> org.exolab.castor.persist.FieldMolder.<init>(FieldMolder.java:583)
> at
> org.exolab.castor.persist.ClassMolder.<init>(ClassMolder.java:367)
> at
> org.exolab.castor.persist.ClassMolder.resolve(ClassMolder.java:519)
> at
> org.exolab.castor.persist.LockEngine.<init>(LockEngine.java:168)
> at
> org.exolab.castor.persist.PersistenceEngineFactory.createEngine(Persiste
> nceEngineFactory.java:83)
> at
> org.exolab.castor.jdo.engine.DatabaseRegistry.<init>(DatabaseRegistry.ja
> va:204)
> at
> org.exolab.castor.jdo.engine.DatabaseRegistry.<init>(DatabaseRegistry.ja
> va:163)
> at
> org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase(DatabaseRegis
> try.java:294)
> at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:583)
> at
> com.vort.ads.utils.ProjectManager.loadProject(ProjectManager.java:486)
> at
> com.vort.ads.gui.project.JFrOpenProject.jBOpenActionPerformed(JFrOpenPro
> ject.....
>
> The interesting part is that it is "accepting/returning object of type
> null was not found" whats up with this? I am using a recent CVS version,
> but I've noticed this happening in older versions as well.
> Any ideas? What am I doing wrong that its not looking for the write
> methods?
>
> Thanks!
> -Nick
>
> -------Original Message-----
> --From: Keith Visco [mailto:[EMAIL PROTECTED]
> --Sent: Tuesday, July 13, 2004 4:00 PM
> --To: [EMAIL PROTECTED]
> --Subject: Re: [castor-dev] Get/set for booleans
> --
> --
> --
> --Hi Nick,
> --
> --Castor supports "isSomething" for booleans, it's working for me.
> --
> --As for specifying only a getter and not the setter. The
> --behavior in Castor is that if you don't specify any accessor
> --methods, Castor will look for them and try and determine them
> --automatically. But if you only specify one, such as the
> --getter, it will not look for the other one, in this case the
> --setter. The basic reason is to allow some fields to be
> --"read-only" or "write-only", depending on which method was specified.
> --
> ----Keith
> --
> --Nick Stuart wrote:
> -->
> --> Ok, this has kind of been annoying me for awhile now and
> --was wondering
> --> if anyone else had the same issue. When ever I do boolean get/set
> --> method the standard get format is Public boolean
> --> isSomethingBlah(){...} But castor complains when I don't supply
> --> specific get-method=""
> --> set-method="" in the mapping file. Is there any reason why we cant
> --> default to the isSomething format when we have a boolean? It is the
> --> standard way to do it that I know of. I'm just wondering if
> --anyone has
> --> been down this road before and found it couldn't be done
> --cleanly. If
> --> not, I'll file an enhancement request pronto and get to
> --modifying. :)
> -->
> --> -Nick
> -->
> --> P.s. Another thing I find weird is that if I only supply the
> --> get-method castor still complains about no set method. Is this
> --> expected? It works fine when I specify it, but I don't
> --think I should have to.
> -->
> -->
> -->
> ------------------------------------------------------------------------
> --> --
> --> -----------------------------------------------------------
> --> 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
