Maybe I'm missing something, but isn't making internal classes public an
inherent security risk? Unless these APIs do security checks
(authorization checks of an authenticated user), then they shouldn't be
public, IMHO. This is especially risky given that Derby supports
server-side Java...
Thanks,
David
Suresh Thalamati wrote:
Hi,
I am looking at creating a new corruptible storage factory by
extending the engine's disk storage factory.
Purpose of this is to do explicitly corrupt the IO and do some
recovery testing. Thought ideal place
for the corruptible storage factory is to be in the test code utilities
not in the code line. But I ran into a simple obstacle ,
constructors in the org.apache.derby.impl.io.DirFile etc are package
protected. So I am unable to extend the disk storage
factory classes successfully .
I was wondering if there was any reason for not making constructors
public or it was just that there was not requirement to do ?
If no one has any objections I would like to modify them to be
accessible outside org.apache.derby.impl.io.* package ?
Thanks
-suresht
