Good find.
Easiest way to get it fixed is to submit a patch ;-)
Otherwise opening a bug in the bug tracker is good, and pinging us on -dev periodically if it doesn't seem anyone is acting on it. That said, this is pretty significant -- it also makes the cd.getTopLevelClass(..) call pretty tricky as it should be capable of returning a tuple now, butthat will break things left and right =/
-Brian
On Jul 8, 2004, at 7:35 AM, Peter Wieland wrote:
Hi again,
I digged a little deeper. The problem occurs in fact, when a class is in
more than one extent. In my example, Product implements two interfaces
TextLinkable and ImageLinkable. I'm afraid this scenario was not one, OJB
developers thougt about.
In DescriptorRepository.addExtent(String classname, ClassDescriptor cld),
mappings between extents and the class descriptors of their superclasses are
stored. If interfaces come into play - i.e. one class may belong to more
than one extent - the last extent added wins as each extent/superclass
mapping uses the extent class name as unique key and thus previously
registered mappings are simply overwritten.
In my example, getBroker().getTopLevelClass(Product.class) returns
ImageLinkable.class. Hence, it is not found in the cache when looking for it
as a TextLinkable (Identity.equals() compares toplevel classes and OIDs).
Is there an easy way to get this fixed?
Regards,
Peter
PS: While writing this mail, I felt like this belongs more to the developer
list. Maybe we can continue discussion there. I sent a copy to both lists.
-----Urspr�ngliche Nachricht----- Von: Peter Wieland [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 8. Juli 2004 10:48 An: [EMAIL PROTECTED] Betreff: Cache and Inheritance
Hi all,
I just wrote the following mail to the user list. Here it is a second more
time for two reasons:
1) I used a mail account not subscribed to the list, hence I do not know
whether it will be accepted.
2) I just updated my App for use with OJB 1.0. The problem did not change.
So forget about my last question whether the problem is fixed or not in 1.0.
It is NOT.
Peter
===
Hi all,
I have the following scenario:
<<interface>> TextLinkable (0..*)---(0..1) TextModule
And a class Product implementing TextLinkable (Product is declared as extent
of TextLinkable in repository).
It now appears that I have different instances of the same Product in my App
which is not what I expect. Normally the use of a cache makes sure that
persistent identity is equivalent to java identity (which works fine in most
cases). I suppose that the cache does not correctly resolve identities when
inheritance comes in to play.
The TextModule class holds a dynamic proxy for the associated TextLinkable.
Is it possible, that, when materializing this proxy, it does not find an
existing Product (which would be the real object in this case) in the cache,
because the cache is searched for classes of runtime type TextLinkable
(there are none, as TextLinkable is an interface)?
I observed the problem with OJB RC5. Is this a known problem? Anybody knows
whether it is fixed in 1.0?
Thanks for any help.
Peter
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
