My problem is this. I need to modify the DataSourceRealm so that failed login attempts are recorded and an account gets locked after a certain number of login failures. I want to subclass the DataSourceRealm but unfortunately some of the key methods, authenticate(x3 params), open and close are declared private. The app is to be deployed at a commercial ISP so changing the DatSourceRealm class directly isn't a possibility. I intend to copy the class and make the appropriate changes as a sibling but it would have been preferable to just override these methods. I would request that the permissions on useful methods in the org.apache.catalina.realm.DataSourceRealm be modified from private to protected to make future changes easier. I am more than happy to do these changes myself and send the modified class to you.
You can achieve it the other (simpler, imho) way round. Provided that you have the table containing user data (username, password) as well as its status (say locked), All you have to do is to create a view selecting only unlocked account table rows and make your DataSourceRealm use this view instead of the table. I see no point in bloating DSR with user-specific/app-specific functionality.
As you say, providing a view will provide some of the required function without code modification. The problem is that if the users fails authentication the counter must be increased, if the users passes authentication the counter is zeroed. That may be possible in a view but I can't see how to do it. This is not a request for user-specific code to be placed in DSR. It is simply an enhancement request to change method visibility from private to protected. This will not 'bloat' the code space. Classes are often used in ways the original designer did not cater for. In attempting to reuse the functionality of DSR through subclassing, problems were encountered. Because methods such as open, close & credentials were private they had to be re-implemented in the subclass even though they were direct copies of the superclass implementations. The authenticate(x2 params) method had to be copied because it relied on the private authenticate(x3 params). Changing the visibility will mean that app-specific subclasses can simply override authenticate(x3). Surely this level of reuse is desirable?
I like this request, and we do want to encourage such extension, especially for such a good use-case. Please send a diff patch against the class with your desired changes.
Made authenticate, open, and close methods protected instead of private.