Hi Brian and the rest, Just started trying to make a patch but as you said, this will "break things left and right". I think the difficulty is not to fix the problem itself but to understand which places are affected by the changes. I could go on trying to get it working but I'm afraid I would have to touch quite a lot of files as this is very deep in the OJB codebase. Hence there are a lot of decisions to make and I'm not sure whether I am the right one to do so.
I'm just a bit afraid of changing things deep in the OJB core as I am not very familiar with your code. What do you think could be a good way to collaborate? Peter -----Urspr�ngliche Nachricht----- Von: Brian McCallister [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 8. Juli 2004 12:45 An: OJB Users List Betreff: Re: AW: Cache and Inheritance 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
