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

On 16 Mar 2007, at 15:21, Brian Stansberry wrote: > 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). Right now we just do a toString() which isn't enough. "1".toString() and new Integer(1).toString() will point to the same node and that's incorrect.

> >> 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. Not necessarily - with JBoss Serialization (2) is no longer an issue.

> 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. Apart from that, a good summary. Feel like adding it to the Javadoc in HEAD? :-)