hi angela, >i wouldn't call extending an interface a backward compatibility issue. ok thats matter of opinion :-) but if we write in the release-notes something like
#Apache Jackrabbit 1.6 is fully compatible with the previous 1.x releases. #A previous Apache Jackrabbit 1.x installation can be upgraded by replacing #the relevant jar files with the new versions and adding some new dependencies. it's not really true. i think a class like the accessmanager will be implemented by a more people so they must change code ... anyway thats not a really big problem. >most calls calls to the old, deprecated methods were replaced within >jackrabit-core. since it is within other people's code i didn't want >to introduce problems and left a couple of calls untouched, where i >somehow felt uneasy to change to it (maybe over-careful). ok i understand .. but thats for me a little bit mixed because in 1.5 all security relevant checks where id based on and now more are path based. In our Accessmanager everything is id based so the path based calls didnt fit our implementation. i know in 2.0 it will be path based and so i changed our Accessmanager to handle everything path based as written in DefaultAccessmanager. >what kind of hints do you exactly expect? Yeah the hint was the DefaultAccessManager :-) thanks anyway greets claus
