> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 19, 2003 11:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: dynamic proxy problem
>
>
> Hello Ken,
>
> > -----Original Message-----
>
> > I was able to make it work by pointing the collection-descriptor and
> > reference-descriptor to AccountImpl instead of Account like
> > below.
>
> fine.
>
> [..]
>
> > Of course I have to cast to Account though.
>
> I do not understand that. Where do you do that cast?
> It is an upcast, isn't it? Then it is never needed in Java.
When retrieving a collection element. That makes sense, now that I typed it,
because the real class is a dynamic proxy not AccountImpl.
>
> > I was also able to make it work by removing the interface from the
> > repository altoghether like this:
>
> [..]
>
> > I was also surprised to find that the Interface doesn't even
> > have to declare
> > any methods and it still works! Now that I've spent 4 hours
>
> The method your interface declares are a matter of your
> application. It is irrelevant to OJB. Even if you add
> field-descriptors to the interface' class-descriptor,
> it still does not matter for OJB which methods
> the interface declares. It is just important that
> each implementing class (or at least each class that
> OJB has to store/retrieve instances of) has corresponding
> fields (or bean accessors, depending on setting of
> PersistentFieldClass in OJB.properties).
>
> > making it work,
> > I'm wondering how it's supposed to work or what best practice
> > others have
>
> I suggest that the fields' types are interfaces. That is good
> practice in Java anyway, and you will need it do use the proxy
> feature. If you expect not to use any other implementation
> of that interface with OJB, there is no need to bother the
> repository_user.xml with it, so I recommend not to mention
> the interface there.
That's what I have in my classes. So you suggest always querying for
implementation classes since OJB will not know of the interfaces? That also
means that collection and reference descriptors must point to AccountImpl
instead of Account right?
>
> > found. All of these methods seem to require my client code to use
> > AccountImpl in some places but Account in others. Is that right?
>
> I do not understand that. Where in your application
> do you need AccountImpl?
In queries since OJB doesn't know of interfaces e.g. Account.
>
> In our application, we have one interface for each
> persistence-capable class. The persistence-capable class
> has OJB-specific fields, but the interface is independent from
> OJB. The rest of the application is programmed against the
> interfaces. If we should ever support another O/R-mapper, we
> have to re-implement the interfaces and provide another
> factory.
OK. My app is also currently programmed against interfaces and gets
instances with Factories. With this approach, I've found that I cannot
mention the interface an OJB query. Someone else suggested I add the
interfaces to the repository so I could query for them. I fell for it but it
seems that approach requires a complete interface hierarchy in the
repository matching the implementation hierarchy. I mean complete with all
field, reference, and collection descriptors. It seems that this only gains
one the ability to use interfaces in queries like:
Query query = QueryFactory.newQuery(Account.class,crit);
instead of implementation classes like:
Query query = QueryFactory.newQuery(AccountImpl.class,crit);
I think I can deal with querying for AccountImpl to avoid all that
duplication the repository. Am I getting this now? Thanks for your help!
>
> Olli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
