On 10/25/05, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > > On 10/26/05, Warner Onstine <[EMAIL PROTECTED]> wrote: > > > That's what was unclear. We initially thought that the class specified > was > > the implementation, not the interface (the docs are not clear on this > > subject). > > > > So, here is our situation, we would like to implement proxies, but we > want > > to do it in a non-invasive way. Should we create a custom proxy class > that > > is used instead? > > First, you should be clear that proxies actually help you. IMO most of > the time they make sense for collections to avoid materializing > elements of the collection. But this is best handled via a collection > proxy. > I tend to use proxies only in collections and in references when they > are back-references (the other end of a collection). And I never > specify them for the class but rather in the reference/collection. For > these references, I introduce interfaces and implementations, which > both of them I map via OJB. This is slightly more complicated but > works like a charm.
Interesting. I'm not sure if this fits with our model, I'll have to investigate a bit on this approach. Btw, you could also try to use CGLib-proxies which are some sort of > auto-generated proxies where no interfaces are needed at all. You > enable them in OJB.properties via the ProxyFactoryClass and the > IndirectionHandlerClass settings, and then use 'dynamic' in your > class-descriptor. > I'm not sure whether they are already in 1.0.3 though, if not then > you'd have to check out OJB from CVS or wait until the 1.0.4 RC that > is due in the next weeks. Excellent, yeah cglib proxies are not in 1.0.3 (as the class we were having issues with is no longer in CVS ;-). -warner Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
