You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br> on 2004/03/14 23:00:47 UTC
PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Sorry. It's working (see DescriptorRepository.discoverDescriptor(Class
clazz) )
What do you thing about using PersistentFieldClass per class descriptors
? That would make the use (access to values) of Dynamic Proxies easier.
For class-descriptors that relate to Dynamic Proxies we could configure
a different PersistentFieldClass, otherwise we could use the
configuration on OJB.properties.
On Fri, 2004-03-12 at 18:10, Thomas Dudziak wrote:
> On Fri, 12 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
>
> > I'm trying to make java.lang.reflect.Proxy objects work with OJB, but I
> > can't , since Proxy.getClass() returns "$Proxy" (and its final) and OJB
> > makes heavy use of ref.getClass() or Class parameters.
> >
> > I'd like to know what you think about a (huge) change on ojb codebase to
> > handle cases like this. Most of the places that expect a Class ref would
> > have to change that to String.
> >
> > Please, I'm trying to change ojb just to fit my needs.
> > If you don't think this is something that OJB should support please let
> > me know. And I'll think about other solution.
>
> I recently changed proxy handling and class-descriptor handling to do
> exactly that: all proxy-stuff within OJB specifically checks for OJB
> proxies (via ProxyHelper: invocation handler is class IndirectionHandler),
> and the method that determines a class descriptor for a given object not
> only uses getClass but also getInterfaces (which is necessary for working
> with proxies). Ad a side effect one can now also specify class descriptors
> for interfaces (using factory-class/-method for creating actual
> objects).
> I also have one app using this feature, though not with
> collections/references.
>
> So, could you please specify what is not working ?
>
> 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
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Brian McCallister <mc...@forthillcompany.com>.
I completely agree that something along these lines should be done (not
the least of which because it will let us expunge the first, and
ugliest, code I contributed to OJB ;-).
I agree with Armin that it is a field-descriptor level setting. The
class descriptor could be a (major convenience) but I would lean
towards implementing it as syntactic sugar in the configuration parser
rather than making that available in the runtime metadata (and
requiring cascaded searches for how to access the field).
Presuming this is for 1.0.1 and/or 1.1...
+1 on field
+0 on class
-1 for introducing it in 1.0
-Brian
On Mar 15, 2004, at 8:57 AM, Leandro Rodrigo Saad Cruz wrote:
> I agree with Thomas.
> Setting the PersistentFieldClass is desirable on both levels, class and
> field descriptors. I can add this feature : if there is a
> persistent-field-class attribute present on a field-descriptor element,
> it overrides the class-descriptor settings. Is that ok ?
>
> I really think this is a desirable feature. I'm trying to use
> DynamicProxy objects work with obj and the PersistentFieldClass must
> call its getters and setters, but this is not true for other objects
> where calling getters/setters is not an option. So, obj should provide
> different PersistentFieldClass at the class/field level.
>
> On Mon, 2004-03-15 at 07:27, 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?
>>
>> regards,
>> Armin
>>
>> Leandro Rodrigo Saad Cruz wrote:
>>> Sorry. It's working (see
>>> DescriptorRepository.discoverDescriptor(Class
>>> clazz) )
>>>
>>> What do you thing about using PersistentFieldClass per class
>>> descriptors
>>> ? That would make the use (access to values) of Dynamic Proxies
>>> easier.
>>>
>>> For class-descriptors that relate to Dynamic Proxies we could
>>> configure
>>> a different PersistentFieldClass, otherwise we could use the
>>> configuration on OJB.properties.
>>>
>>> On Fri, 2004-03-12 at 18:10, Thomas Dudziak wrote:
>>>
>>>> On Fri, 12 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
>>>>
>>>>
>>>>> I'm trying to make java.lang.reflect.Proxy objects work with OJB,
>>>>> but I
>>>>> can't , since Proxy.getClass() returns "$Proxy" (and its final)
>>>>> and OJB
>>>>> makes heavy use of ref.getClass() or Class parameters.
>>>>>
>>>>> I'd like to know what you think about a (huge) change on ojb
>>>>> codebase to
>>>>> handle cases like this. Most of the places that expect a Class ref
>>>>> would
>>>>> have to change that to String.
>>>>>
>>>>> Please, I'm trying to change ojb just to fit my needs.
>>>>> If you don't think this is something that OJB should support
>>>>> please let
>>>>> me know. And I'll think about other solution.
>>>>
>>>> I recently changed proxy handling and class-descriptor handling to
>>>> do
>>>> exactly that: all proxy-stuff within OJB specifically checks for OJB
>>>> proxies (via ProxyHelper: invocation handler is class
>>>> IndirectionHandler),
>>>> and the method that determines a class descriptor for a given
>>>> object not
>>>> only uses getClass but also getInterfaces (which is necessary for
>>>> working
>>>> with proxies). Ad a side effect one can now also specify class
>>>> descriptors
>>>> for interfaces (using factory-class/-method for creating actual
>>>> objects).
>>>> I also have one app using this feature, though not with
>>>> collections/references.
>>>>
>>>> So, could you please specify what is not working ?
>>>>
>>>> Tom
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Brian McCallister <mc...@forthillcompany.com>.
There is already a PersistentFieldAutoDetectThingieMaBob in OJB which
first looks for field acccess, then tries bean property, then tries
dynabean, then gives up. It is a bit ugly as the reflection API throws
an exception to signal it cannot find something, but I have used it and
it works.
-Brian
On Mar 15, 2004, at 9:05 AM, Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
>
>> I really think this is a desirable feature. I'm trying to use
>> DynamicProxy objects work with obj and the PersistentFieldClass must
>> call its getters and setters, but this is not true for other objects
>> where calling getters/setters is not an option. So, obj should provide
>> different PersistentFieldClass at the class/field level.
>
> A quick fix for you would be to combine the two field handlers to one
> handler that first tries to access the field directly, and if that
> fails,
> searches for accessors (the 'fast' way) or vice versa (the 'safe' way
> in
> case the getters/setters do something other than returning/setting the
> field).
> I'd rather avoid doing big metadata changes before 1.0, and such a
> handler
> would be useful anyway.
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
> I really think this is a desirable feature. I'm trying to use
> DynamicProxy objects work with obj and the PersistentFieldClass must
> call its getters and setters, but this is not true for other objects
> where calling getters/setters is not an option. So, obj should provide
> different PersistentFieldClass at the class/field level.
A quick fix for you would be to combine the two field handlers to one
handler that first tries to access the field directly, and if that fails,
searches for accessors (the 'fast' way) or vice versa (the 'safe' way in
case the getters/setters do something other than returning/setting the
field).
I'd rather avoid doing big metadata changes before 1.0, and such a handler
would be useful anyway.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC]
Using java.lang.reflect.Proxy
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
I agree with Thomas.
Setting the PersistentFieldClass is desirable on both levels, class and
field descriptors. I can add this feature : if there is a
persistent-field-class attribute present on a field-descriptor element,
it overrides the class-descriptor settings. Is that ok ?
I really think this is a desirable feature. I'm trying to use
DynamicProxy objects work with obj and the PersistentFieldClass must
call its getters and setters, but this is not true for other objects
where calling getters/setters is not an option. So, obj should provide
different PersistentFieldClass at the class/field level.
On Mon, 2004-03-15 at 07:27, 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?
>
> regards,
> Armin
>
> Leandro Rodrigo Saad Cruz wrote:
> > Sorry. It's working (see DescriptorRepository.discoverDescriptor(Class
> > clazz) )
> >
> > What do you thing about using PersistentFieldClass per class descriptors
> > ? That would make the use (access to values) of Dynamic Proxies easier.
> >
> > For class-descriptors that relate to Dynamic Proxies we could configure
> > a different PersistentFieldClass, otherwise we could use the
> > configuration on OJB.properties.
> >
> > On Fri, 2004-03-12 at 18:10, Thomas Dudziak wrote:
> >
> >>On Fri, 12 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
> >>
> >>
> >>>I'm trying to make java.lang.reflect.Proxy objects work with OJB, but I
> >>>can't , since Proxy.getClass() returns "$Proxy" (and its final) and OJB
> >>>makes heavy use of ref.getClass() or Class parameters.
> >>>
> >>>I'd like to know what you think about a (huge) change on ojb codebase to
> >>>handle cases like this. Most of the places that expect a Class ref would
> >>>have to change that to String.
> >>>
> >>>Please, I'm trying to change ojb just to fit my needs.
> >>>If you don't think this is something that OJB should support please let
> >>>me know. And I'll think about other solution.
> >>
> >>I recently changed proxy handling and class-descriptor handling to do
> >>exactly that: all proxy-stuff within OJB specifically checks for OJB
> >>proxies (via ProxyHelper: invocation handler is class IndirectionHandler),
> >>and the method that determines a class descriptor for a given object not
> >>only uses getClass but also getInterfaces (which is necessary for working
> >>with proxies). Ad a side effect one can now also specify class descriptors
> >>for interfaces (using factory-class/-method for creating actual
> >>objects).
> >>I also have one app using this feature, though not with
> >>collections/references.
> >>
> >>So, could you please specify what is not working ?
> >>
> >>Tom
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >>For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> 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
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Armin Waibel wrote:
> I don't know if it is allowed to ship OJB with BSD-style licence jars.
> Why you want to use dom4j - dom-parser or sax+xpath to map metadata?
As I already wrote in an earlier mail
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=6526),
there are several issues with this policy (we might not even be allowed
to ship the xml-apis.jar among others), and from what I read it is not per
se required by the license itself.
I like dom4j because it is really simple to use, powerful, and most XML
related stuff can be done in only a small number of lines of code
(e.g. parsing/writing, working with the tree, XSLT transformation
...). However I didn't want to advertize, it is only one of the
possibilities that came to my mind.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Armin Waibel <ar...@apache.org>.
Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Armin Waibel wrote:
>
>
>>yep, in OJB.properties the path to the repository file was specified
>>(maybe we should change this in 1.1) and many default/standard classes
>>(e.g. PersistentFieldClass) are defined. I like this, because it
>>prevents us to define default implementation classes in source code,
>>respectively allow us to change these classes.
>
>
> I agree when we're starting OJB normally (e.g. obtaining a persistence
> broker or whatever), but this IMO should not be necessary when using
> metadata only ?
>
The problem is that the metadata classes aren't only simple java bean
style classes (only getter/setter for properties), rather we implement
much application logic in these classes, thus we need some classes set
in OJB.properties.
I agree it would be a better design when metadata handling will be
decoupled from OJB.properties file. How should we do that? Do we need a
FieldDescriptorBean (encapsulates metadata properties only) and
FieldDescriptor (application logic) class?
>
>>I think it's decoupled. At least I assert this behaviour in these
>>uncomplete doc ;-)
>>http://db.apache.org/ojb/metadata.html
>>
>>You can load connection metadata different from persistent object
>>metadata and vice versa. In object metadata no connection specific stuff
>>is used.
>
>
> If it is, all the better (don't remember about the connection
> descriptor). I'll check. As I said, I can also write some tests later on
> if required.
>
Starting with an "empty repository" file works for me.
>
>>Great! April is ok, at that time 1.0 should be released ;-)
>>(dom4j licence?)
>
>
> Dom4j is BSD-style.
>
I don't know if it is allowed to ship OJB with BSD-style licence jars.
Why you want to use dom4j - dom-parser or sax+xpath to map metadata?
regards,
Armin
> Tom
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Armin Waibel wrote:
>
> > yep, in OJB.properties the path to the repository file was specified
> > (maybe we should change this in 1.1) and many default/standard classes
> > (e.g. PersistentFieldClass) are defined. I like this, because it
> > prevents us to define default implementation classes in source code,
> > respectively allow us to change these classes.
>
> I agree when we're starting OJB normally (e.g. obtaining a persistence
> broker or whatever), but this IMO should not be necessary when using
> metadata only ?
Forget that, I didn't think that through :-)
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Armin Waibel wrote:
> yep, in OJB.properties the path to the repository file was specified
> (maybe we should change this in 1.1) and many default/standard classes
> (e.g. PersistentFieldClass) are defined. I like this, because it
> prevents us to define default implementation classes in source code,
> respectively allow us to change these classes.
I agree when we're starting OJB normally (e.g. obtaining a persistence
broker or whatever), but this IMO should not be necessary when using
metadata only ?
> I think it's decoupled. At least I assert this behaviour in these
> uncomplete doc ;-)
> http://db.apache.org/ojb/metadata.html
>
> You can load connection metadata different from persistent object
> metadata and vice versa. In object metadata no connection specific stuff
> is used.
If it is, all the better (don't remember about the connection
descriptor). I'll check. As I said, I can also write some tests later on
if required.
> Great! April is ok, at that time 1.0 should be released ;-)
> (dom4j licence?)
Dom4j is BSD-style.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Armin Waibel <ar...@apache.org>.
Hi again Tom,
Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Armin Waibel wrote:
>
>
>>hmm, ok so we need both possibilities to define PersistentFieldClass
>>attribute filed- and class-descriptor level
>>and I fear the worst you want this feature for 1.0 ;-)
>
>
> Nope, for 1.1 is enough, I think. The workaround using the field handler
> that Brian mentioned should do for the 1.0, though there should be some
> note of it in the docs.
>
puh! For 1.1 I will agree all proposals ;-)
>
>>do we need this? One reason is that we do not separate metadata
>>properties and functionality/service methods in metadata classes.
>
>
> I had one application where I simply wanted to manipulate the metadata
> without doing any database-related stuff. However, currently OJB requires
> me to provide OJB.properties
yep, in OJB.properties the path to the repository file was specified
(maybe we should change this in 1.1) and many default/standard classes
(e.g. PersistentFieldClass) are defined. I like this, because it
prevents us to define default implementation classes in source code,
respectively allow us to change these classes.
>, and a connection descriptor (I may be
> mistaken about that one) when using the metadata even though they are not
> actually needed by the metadata stuff.
I must confess that I'm not sure about connection-descriptor too (it was
possible in the past). But I think if you access metadata via
MetadataManager it should be possible. If not, you found a bug.
http://db.apache.org/ojb/faq.html#Start OJB without a repository file?
> I strongly believe that metadata handling and database stuff should be as
> decoupled as possible, in extreme with using interfaces (facade) which are
> backed by XML i/o (as we have it now) or other stuff, e.g. database (->
> MOF ?), Language-supported metadata (JSR 175) etc.
>
I think it's decoupled. At least I assert this behaviour in these
uncomplete doc ;-)
http://db.apache.org/ojb/metadata.html
You can load connection metadata different from persistent object
metadata and vice versa. In object metadata no connection specific stuff
is used.
>
>>I think this is really important for 1.0.
>>All these known issues should be noted in the release-notes.
>>Can you list the (most important) properties of class-/field-descriptor
>>who don't support runtime changes?
>
>
> I believe there were some mails on the lists. I can have a look and
> summarize them.
>
This will be great!
>
>>I agree. But what are the alternatives and who will be willing to do
>>this changeover?
>
>
> I'd be willing to rework the XML parsing part (using dom4j or the like
> ?) but not before April (too much regular work and deadlines too near).
>
Great! April is ok, at that time 1.0 should be released ;-)
(dom4j licence?)
regards,
Armin
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Armin Waibel wrote:
> hmm, ok so we need both possibilities to define PersistentFieldClass
> attribute filed- and class-descriptor level
> and I fear the worst you want this feature for 1.0 ;-)
Nope, for 1.1 is enough, I think. The workaround using the field handler
that Brian mentioned should do for the 1.0, though there should be some
note of it in the docs.
> do we need this? One reason is that we do not separate metadata
> properties and functionality/service methods in metadata classes.
I had one application where I simply wanted to manipulate the metadata
without doing any database-related stuff. However, currently OJB requires
me to provide OJB.properties, and a connection descriptor (I may be
mistaken about that one) when using the metadata even though they are not
actually needed by the metadata stuff.
I strongly believe that metadata handling and database stuff should be as
decoupled as possible, in extreme with using interfaces (facade) which are
backed by XML i/o (as we have it now) or other stuff, e.g. database (->
MOF ?), Language-supported metadata (JSR 175) etc.
> I think this is really important for 1.0.
> All these known issues should be noted in the release-notes.
> Can you list the (most important) properties of class-/field-descriptor
> who don't support runtime changes?
I believe there were some mails on the lists. I can have a look and
summarize them.
> I agree. But what are the alternatives and who will be willing to do
> this changeover?
I'd be willing to rework the XML parsing part (using dom4j or the like
?) but not before April (too much regular work and deadlines too near).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Armin Waibel <ar...@apache.org>.
Hi Thomas,
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).
>
hmm, ok so we need both possibilities to define PersistentFieldClass
attribute filed- and class-descriptor level
and I fear the worst you want this feature for 1.0 ;-)
> 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;
do we need this? One reason is that we do not separate metadata
properties and functionality/service methods in metadata classes.
> some of the accessors have
> other names than the properties they represent;
yes, this should be refactored before 1.1
> there are values where a
> runtime change is not well supported, etc.)
I think this is really important for 1.0.
All these known issues should be noted in the release-notes.
Can you list the (most important) properties of class-/field-descriptor
who don't support runtime changes?
> , 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 ?
>
I agree. But what are the alternatives and who will be willing to do
this changeover?
regards,
Armin
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
> No. We can check if we are dealing with a proxy object using
> Proxy.isProxyClass.
That might be possible (though this call is costly), but have you checked
that the lookup happens every time for any proxy object, or is the class
descriptor cached ? The interface solution should be in place anyway as it
allows to specify interfaces in the repository descriptor (using
facade-class/-method).
> You can't change the way your proxies are created ?
Nope, I cannot change the business part at all (and even if I could, the
proxies are created by some aspect-oriented stuff, so I'd still be out of
luck). That's a nice property of OJB: I can specify the repository
descriptor and control creation and initialization with external classes
(factory-class/method, initialization-method) without having to touch the
business logic at all.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Mon, 2004-03-15 at 11:39, Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
>
> > 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.
>
> That wouldn't be good as this would require all non-ojb proxies to
> implement an (probably empty) interface.
No. We can check if we are dealing with a proxy object using
Proxy.isProxyClass.
> I for one have an application
> where I have no control whatsoever about the proxying stuff so that
> wouldn't work for me at all.
You can't change the way your proxies are created ?
> If the class returned by the proxy is stable (i.e. always the same class
> object) which is likely, then the lookup happens only once anyway as the
> class descriptor is cached.
> 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
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 15 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
> 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.
That wouldn't be good as this would require all non-ojb proxies to
implement an (probably empty) interface. I for one have an application
where I have no control whatsoever about the proxying stuff so that
wouldn't work for me at all.
If the class returned by the proxy is stable (i.e. always the same class
object) which is likely, then the lookup happens only once anyway as the
class descriptor is cached.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
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
Re: PersistentFields per class descriptors. was [RFC] Using
java.lang.reflect.Proxy
Posted by Thomas Dudziak <to...@first.gmd.de>.
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
Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Posted by Armin Waibel <ar...@apache.org>.
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?
regards,
Armin
Leandro Rodrigo Saad Cruz wrote:
> Sorry. It's working (see DescriptorRepository.discoverDescriptor(Class
> clazz) )
>
> What do you thing about using PersistentFieldClass per class descriptors
> ? That would make the use (access to values) of Dynamic Proxies easier.
>
> For class-descriptors that relate to Dynamic Proxies we could configure
> a different PersistentFieldClass, otherwise we could use the
> configuration on OJB.properties.
>
> On Fri, 2004-03-12 at 18:10, Thomas Dudziak wrote:
>
>>On Fri, 12 Mar 2004, Leandro Rodrigo Saad Cruz wrote:
>>
>>
>>>I'm trying to make java.lang.reflect.Proxy objects work with OJB, but I
>>>can't , since Proxy.getClass() returns "$Proxy" (and its final) and OJB
>>>makes heavy use of ref.getClass() or Class parameters.
>>>
>>>I'd like to know what you think about a (huge) change on ojb codebase to
>>>handle cases like this. Most of the places that expect a Class ref would
>>>have to change that to String.
>>>
>>>Please, I'm trying to change ojb just to fit my needs.
>>>If you don't think this is something that OJB should support please let
>>>me know. And I'll think about other solution.
>>
>>I recently changed proxy handling and class-descriptor handling to do
>>exactly that: all proxy-stuff within OJB specifically checks for OJB
>>proxies (via ProxyHelper: invocation handler is class IndirectionHandler),
>>and the method that determines a class descriptor for a given object not
>>only uses getClass but also getInterfaces (which is necessary for working
>>with proxies). Ad a side effect one can now also specify class descriptors
>>for interfaces (using factory-class/-method for creating actual
>>objects).
>>I also have one app using this feature, though not with
>>collections/references.
>>
>>So, could you please specify what is not working ?
>>
>>Tom
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org