Manik Surtani wrote:
On 15 Mar 2007, at 18:24, Brian Stansberry wrote:
> Manik Surtani wrote:
>> I think we're going to need to support non-String Fqns. We're not
>> going away from that anytime soon. :S
>
> Good. I'm not positive, but I think the only place non-String Fqns
> are irreparably broken is with a preload call to a cache loader.
Well, any config file element that uses Fqns. Eviction policies, for
example. But that's a limitation on the config file, nothing else.
We should think about improving handling this for configurations built
by a DI framework.
> With other cache loader calls, the real fqn is available as a
call
> parameter, so the string-based representation used for the persistent
> store doesn't have to leave the cache loader.
Yeah, that can be worked around. What do you reckon the best approach
for "encoding" Fqns are, for CLs that only use Strings?
For each Fqn element, "Type:" + element.getClass() + ":value:" +
element.toString() ?
Not sure why what we do now isn't sufficient (confession - haven't
really looked).
Could barf with user objects that don't override toString() and you have
object hash codes...
Yeah, if element.toString() doesn't provide a stable, unique id for
element, then element's type is not appropriate for use in an Fqn with a
cache loader.
This is a bit complex, but can be summarized in a prominent doc page
(and javadoc) on Fqn:
1) If cache is LOCAL with no cache loader, any Object will do.
2) If cache is replicated with no cache loader, any Serializable will do.
3) If a cache loader is used, for each type 'element' in the Fqn
element.toString() must provide a stable, unique id for element. Default
Object.toString() is no good; most (if not all) java.lang.Number classes
are fine. A toString() impl that lists the class and the field
name-value pairs for all the fields that go into an equals() evaluation
is good.
4) If a cache loader is used and you want to use preload, the type must
be String.
CC'ing dev list, BTW.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com