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.
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() ?
Could barf with user objects that don't override toString() and you
have object hash codes...
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