On 12/18/2013 12:05 PM, Daniel Fuchs wrote:
But then we have another problem with doPrivileged approach, since it is
even more restrictive than 'sealed' field approach. Currently the
Handler's subclass that overrides a setter and calls super, works:
@Override
public void setOutputStream(OutputStream out) {
super.setOutputStream(out);
}
With doPrivileged wrapping setOutputStream in the superclass
constructor, it will throw SecurityException if the subclass protection
domain does not have the "control" permission...
Can this break custom handlers in some environment?
Good question. It may yes - but on the other hand, a subclass of
handler that override such methods and call the super.method would
*need* to have the control permission too - wouldn't it?
Otherwise calling these methods when sealed is back to true would
always fail...
There might be no need to call the overridden setters after the Handler
instance is constructed. Apart from "setLevel", Handler setters are only
called by Handlers themselves in construction phase and by user code...
If user code doesn't need to call the overridden setters after handlers
are constructed, user code doesn't need the "control" permission.
But than again, user would *need* to have "control" permission anyway to
make use of a newly constructed Handler. If all she can do is
instantiate new Handler instances and not add them to Loggers, what good
does it make?
Regards, Peter
best regards,
-- daniel
