[infinispan-dev] Reading data differs from a WAR deployment or an EAR deployment

[Sanne Grinovero]

2011/9/1 Sanne Grinovero <sanne at infinispan.org>:
> update
> it might just be a trivial error: duplicate jars on the classpath,
> make the equals fail on the key when looking up a value from the
> container.
>
> This happened to myself once already and costed us some tear and
> blood; I'm tempted to add a check for this to log a fat warning, but
> this would have an overhead on a very hot path: to verify when the
> class instances are different if their names where actually equal, to
> be checked for each key comparison in happening during a cache lookup.
>
> I'm thinking to add such check only if the debug/trace level are
> enabled; still that would check for the debug level potentially many
> times per query execution, do I'll check the logging level statically
> .. better than nothing.
>
> WDYT ?
>
Extending the idea: today we've hit this issue on this specific key
implementation, but it's in no way specific to Lucene, it could happen
to anybody using Infinispan, with any key type both he's own custom
keys or our "framework keys" such as those used by Lucene or OGM.

Would it make sense to have an option which wraps all keys in the
container to do such a check? That would be able to quickly identify
classloading ambiguities, and being an Infinispan configuration option
it is a bit more intuitive to deal with than changing the behaviour
according to log levels.

Sanne