Thomas:

Thanks for your reply.

I am already at version 1.17 of
AbstractPersistentField .

I have already tried overriding computeField(), and in
it calling AbstractPersistentField.computeField(); I
catch the MetadateException and then try to replace
the interface Class with an actual implementer Class. 
The problem is that the interface Class I need to
replace is not the one I pass in to computeField(),
but the one that is the next level down (in the
recursion chain).  This is done in the private
methods, and so I have no way to modify that behavior.

Am I explaining this in such a way as to make the
problem clear?  If methods getFieldRecursive() and
getNestedFieldRecursive() were protected, I could
modify them and substitute my implementer Class for
the interface Class when needed...

The actual exception thrown is originally a
NoSuchFieldException thrown from getFieldRecursive().

Gary

--- Thomas Dudziak <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Mar 2004, Gary wrote:
> 
> > I am wondering why the methods getFieldRecursive()
> and
> > getNestedFieldRecursive() in class
> > AbstractPersistentField are private.  I would like
> to
> > have the ability to override them in a custom
> > persistent field implementation.
> > 
> > Here is my dilemma:
> > 
> > I have the following classes:
> > 
> > package ojb;
> > 
> > public interface IParent {
> >     IChild getChild();
> >     void setChild(IChild child);
> > }
> > 
> > package ojb;
> > 
> > public interface IChild {
> >     String getDescription();
> >     void setDescription(String description);
> > }
> > 
> > package ojb;
> > 
> > public class Parent implements IParent {
> >     private IChild child = null;
> >     
> >     public Parent() {
> >             super();
> >     }
> > 
> >     public IChild getChild() {
> >             return child;
> >     }
> > 
> >     public void setChild(IChild child) {
> >             this.child = child;
> >     }
> > 
> > }
> > 
> > package ojb;
> > 
> > public class Child implements IChild {
> >     private String description = null;
> >     
> >     public Child() {
> >             super();
> >     }
> > 
> >     public String getDescription() {
> >             return description;
> >     }
> > 
> >     public void setDescription(String string) {
> >             description = string;
> >     }
> > 
> > }
> > 
> > 
> > 
> > I have the following OJB metadata.
> > <field-descriptor
> > name="child::description"
> >       column="childDescription"
> >       jdbc-type="VARCHAR"
> > />
> >   
> > I am using a subclass of
> > PersistentFieldIntrospectorImpl.  The problem is
> that
> > when it tries to resolve “child::description,” it
> ends
> > up going through the “IChild getChild()” method
> > signature.  This causes it to analyze the fields
> of
> > IChild; of course there aren’t any, so it fails
> with a
> > MetadataException.
> > 
> > If I could override methods getFieldRecursive()
> and
> > getNestedFieldRecursive(), I could substitute at
> run
> > time a class that implements IChild.
> > 
> > Any ideas?  I really need to return a reference to
> an
> > interface here, rather than to a concrete class,
> as
> > our design is heavily interface based.
> 
> Have you tried the CVS version ? I made some changed
> that may be of
> interest to you:
> 
> * methods getFieldRecursive and
> getNestedRecursiveField are static and,
> though still private, you can use them via the
> protected static method
> computeField in AbstractPersistentField
> 
> * I fixed getFieldRecursive such that it no longer
> throws an exception
> when given an interface
> 
> * support for interfaces in the repository
> descriptor is now much
> better; specifically using
> PersistentFieldIntrospectorImpl
> (bean-access) or PersistentFieldAutoProxyImpl
> (detects access method
> automatically - best for mixing concrete classes and
> interfaces) should
> work much better now
> 
> Perhaps you could try the CVS version with the
> unmodified
> PersistentFieldIntrospectorImpl, and if you still
> have problems, then
> please post the stacktrace ?
> 
> Tom
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to