Marc,
> Whereas I insist that "ease of use" is the main goal (i.e. that in 80%
cases
> developers are going to create and call methods to bench complex PKs and
> most will not override the hash equals correctly or effectively) and in
that
> case we are sitting much prettier, I also believe it is not an absolute
> priority to introduce some complexity in the cache at this point.
I truly belive the "ease of use" ("breeze"? :) ) that characterizes jBoss is
an essential edge for us.
> I will make the cache structures pluggable so we can use either the base
> cache or the advanced one based on jboss.xml. That is what the
architecture
> is there for and only the client needs to be a bit smarter but that is
minor
> changes. The EntityInstanceCache is also imho a missing piece of the
puzzle
> and I will add that but the implementation of the actual cache will be the
> old one. Use the new one as needed, pluggable.
>
> How does this sound?
Sounds right as rain. :)
If you're talking what i'm thinking, this is what I meant in my post "Re:
[jBoss-Dev] Da solution" what I said that when I digged thru the source
three I'd found out that "jBoss' implementation is tightly coupled with the
idea of strict spec compliance - using the bean's PK" and that "there could
have been one other level of indirection, or abstraction, in this code, so
that we would be able to have implementations of Persistence Managers
without knowing about FastKeys at all, and then possibly write specific code
to handle this elsewhere"(sic).
Looks like the XP iterational process is really something! :)
Keep on the excelent work! (by the way, mail me if you can. I'd love to
actively participate in jBoss in more ways than just pushing people around
on the mailing lists... :) )
Cheers,
Hugo
>
> regards
> marc
>
>
> ________________________
> Marc Fleury, Ph.D.
> Chief Technology Officer
> Telkel, Inc.
> ________________________
>
>
