Hi Stefan,
Stefan Guggisberg wrote: > >> Is this logged at warning level for a reason, and worth >> worrying about? And any quick thoughts on what might have >> changed? > > it's logged as warning because normally it shouldn't happen. > i'd say it's definitely something worth to further investigate. > i can't find the warning in my logs therefore i guess it's > related to your custom AccessManager code. > > do you share the same session with multiple threads? > On closer inspection, it seems the issue is in ItemManager.getItem(ItemId). Previously (v. 1.0.1), this method called the AccessManager first, then checked the cache, then created the node if necessary. Now it seems an optimization has been made where it checks the cache first, and skips the access check if it is cached. In our case, the node actually gets pulled into the cache by a custom access manager, in between the cache check and the creation of the item, hence the warning. But more seriously, the access check might not even be enforced later, since the node was added to the cache. It may not be a common need, but does it seems the old version was much preferable for us. Also, if I understand it correctly, it is a little risky using the cache to enforce the access check, and this might affect others... For instance, couldn't some access manager implementations revoke read access even after an item has been read once previously in a (perhaps long-lived) session? (In fact, the old implementation seemed to accomodate this explicitly, as it evicted the node from cache on access failure.) Thanks again. Cheers, Joshua -- View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7128759 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
