you *don't* have to use the concrete type for the field value but you
*do* have to use a concrete type (obviously one that implements the
field type) in the mapping file.

the upshot of this is that you cant have more than one concrete class
for your interface if you want to use it with castor. but on the other
hand it does mean you can write property assessors based on interfaces
which will help you in the future of castor does get better support for
polymorphism.

oliver



-----Original Message-----
From: Pasupuleti, Bharath [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 8 November 2001 11:21 AM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Very Urgent : Support for interfaces


I agree with you that Castor accepts Collection as a parameter.But, I am
talking in general about interfaces defined for a product or
application,
not the Java API library interfaces.

For example, 

I can define a interface "InterfaceA" and have a class "ClassA"
implement
"InterfaceA".

Let's say I have "InterfaceA", "ClassA" & "ClassB" defined as follows -


interface InterfaceA
{
        .....
        .....
}

class ClassA implements InterfaceA
{
        
}
        

class ClassB
{
        private <type> obj = null;

        public void setObj(<type> obj)
        {
                this.obj = obj
        }

        public <type> getObj()
        {
                return obj;
        }
}


Now in ClassB, if the <type> of obj in the field declaration & get/set
methods is specified as "ClassA" and correspondingly in the mapping
file, if
the <type> of obj is specified as "ClassA" in the field mapping of
ClassB,
Castor JDO works fine.

But if the <type> is specified as "InterfaceA" both in the Java code and
mapping file, Castor JDO fails. If the interface is specified as the
<type>,
it throws an exception.

>From this example, my understanding is that Castor JDO does not support
interface as the return type of set-method or as a parameter of the
get-method. This made me conclude that Castor JDO mappings cannot handle
the
case as expalined above.

Now, I want to confirm whether I am right in concluding that the <type>
has
to be a concrete class only and not interface.

Please clarify my question.

Thank you,

Bharath


-----Original Message-----
From: Toni Charlot [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 07, 2001 3:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Very Urgent : Support for interfaces


I'd say yes since Castor uses Collection which is an Interface. The
get/set
methods for a Collection field returns Collection and accepts Collection
as
a parameter.

-----Original Message-----
From: Pasupuleti, Bharath [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 07, 2001 5:30 PM
To: [EMAIL PROTECTED]
Subject: [castor-dev] Very Urgent : Support for interfaces


Hi,

>From the documentation, I understand that polymorpic collection is not
supported by Castor.

I have a class defined whose get/set methods use interface instead of
actual
concrete classe. It throws exceptions that the interface type is not
recognizable. But, if I change the return type or the parameter to the
concrete class(which implements the same interface) it works.

I want to know if Castor supports interfaces as the return type of
getMethods or accept interface types as parameters for setMethods.
Should
the types be concrete classes only? Can they be interfaces?


Bharath

-----------------------------------------------------------
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

Reply via email to