It seems so simple now. Thanks. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2003 1:36 PM > To: [EMAIL PROTECTED] > Subject: RE: dynamic proxy problem > > > Hello Ken, > > > -----Original Message----- > > From: Ken Brewer [mailto:[EMAIL PROTECTED] > > [..] > > > > > 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 understand. You are right, and it is not an upcast. > > [...] > > > > 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? > > 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. > > Oh yes, the queries. I had forgotten about those. In our > application, we have encapsulated the OJB queries, too, and > we use Strings to specify the class names there. This way, > the application never uses the OJB classes. > > If you want to keep the option of switching to another > O/R-mapper, you have to do that anyway. > > But I would not say that everybody should do it that way. > > [..] > > > 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); > > o.k., I see your point. Yes, if you want the application not > to use AccountImpl and you do not want to encapsulate the queries, > then OJB has to know about the interface in some way, i.e., > it has to be in the repository_user.xml. > In that case, I recommend that your reference-descriptors > nevertheless use AccountImpl as the class. > > 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]
