From the description in this forum post, it looks like we are logging a WARN message every time we determine that a finder select statement can't be cached (for whatever reason).
o This message should probably not be a WARN message. It's a TRACE message, at best. We attempt to cache whenever we can, but if we can't cache something for whatever reason, customers don't want to see these WARN messages. But, if we're trying to debug a caching situation, then having the TRACE message might prove useful.
o I looked (very) briefly at the code and it's not clear as to why this particular finder can't be cached. Some additional data in the TRACE message may help with making the finder cacheable. Or, at least help explain why it's not cacheable.
Since Pinaki seems to have integrated these caching messages, I figured he would be a good initial assignee for the JIRA...
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|19d 16h 49m||1||Donald Woods||09/Mar/10 15:27|
|3h 1m||1||Donald Woods||09/Mar/10 18:29|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Field||Original Value||New Value|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Fix Version/s||2.0.0-beta2 [ 12314802 ]|
|Fix Version/s||2.0.0 [ 12314019 ]|
|Resolution||Fixed [ 1 ]|