Removal of createRestrictor makes custom restrictors difficult #284
Comments
I've re-added the hooks, could you please check, whether this fits your purpose ? BTW, you could always configure a restrictor class name which would get instantiated by the servlet. |
I saw the diff. It looks good to me. We couldn't do servlet configuration as you suggest in this case because we're adding standalone support to an otherwise sealed (non-web) daemon on the command line. We wanted to upgrade so we could get obfuscated SSL keystore password support, but ran into this... Sent from my iPhone
|
In 1.3.3 the protected createRestrictor() call was removed. The only avenue now for creating a custom restrictor is via the constructor. This is problematic as we override init() to perform configuration, and that happens after construction. The instance variable is private and there is no setter, so there's no way to replace the restrictor after construction.
Either the protected createRestrictor() needs to come back, or the instance variable needs to be made protected rather than private or a protected setter added to allow subclasses to replace the restrictor between construction and the call to super.init() (or perhaps even at other times).
The text was updated successfully, but these errors were encountered: