db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leandro Rodrigo Saad Cruz <lean...@ibnetwork.com.br>
Subject Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Date Mon, 15 Mar 2004 14:22:19 GMT
I agree with you. however I think we could improve the way obj looks up
class-descriptors for DynamicProxy objects.

DescriptorRepository.discoverDescriptor(Class clazz) calls
obj.getClass().getInterfaces() and loops through the interface array
searching for a class-desc for each interface.
Couldn't we improve that using something like this

Class classOfProxy = ((DynamicProxy)proxy).getClassOfProxy().

then, proxy objects would have to implement DynamicProxy interface.

On Mon, 2004-03-15 at 09:31, Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Armin Waibel wrote:
> > Hi Leandro,
> > 
> > I agree that PersistentFieldClass configuration isn't flexible today 
> > (setting the standard class in OJB.properties may not fit all 
> > application ranges).
> > 
> > But I don't like setting PersistentFieldClass on class-descriptor level, 
> > because PersistentFieldClass is associated with field-descriptor/field 
> > attribute - it's a field-descriptor attribute.
> > E.g. if a user use java bean style setter/getter in all persistent 
> > capable classes and PersistentFieldIntrospectorImpl as standard 
> > PersistentFieldClass (set in OJB.properties). But for PK/FK fields he 
> > doesn't want to define setter/getter. Then it would be a useful 
> > improvement to allow setting of PersistentFieldClass on field-descriptor 
> > level (then user could specify PersistentFieldDirectAccessImpl for all 
> > PK/FK fields and standard PersistentFieldClass, in this example 
> > PersistentFieldIntrospectorImpl, for all other fields).
> > 
> > In future and if users request setting PersistentFieldClass on 
> > class-descriptor level, it could be a "convenience setting" if users 
> > don't want to define PersistentFieldClass on each field-descriptor.
> > But I don't recommend this, because it will make handling of metadata 
> > runtime changes more and more complex (e.g. user change 
> > PersistentFieldClass on class-descriptor at runtime).
> > 
> > -1, allow setting of PersistentFieldClass on class-descriptor level.
> > Or is this setting imperative to make something work?
> I agree and disagree.
> I disagree because I believe this is a desirable feature on both the class
> and field level especially for fine-tuning (one class requires
> bean-property access whereas other classes can do with direct field access
> which is way faster) and situations where you don't want to expose fields
> via getters/setters (and private accessors only because the field handler
> needs them are somewhat awkward).
> I agree that this would make metadata handling more complex, however as
> there other issues with the metadata handling as it is (e.g. it does not
> work standalone, i.e. without other OJB stuff; some of the accessors have
> other names than the properties they represent; there are values where a
> runtime change is not well supported, etc.), perhaps we should invest some
> work in the metadata handling (and the parsing, IMO the XML metadata
> parser is ugly and unflexible) for 1.1 ?
> Tom
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
Leandro Rodrigo Saad Cruz
InterBusiness Tecnologia e Servi├žos
IB    - www.ibnetwork.com.br
DB    - www.digitalbrand.com.br
OJB   - db.apache.org/ojb
XINGU - xingu.sf.net

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message