Mamta Satoor wrote:
I just wanted to share that I was able to fix the problem. The problem
was that I was not reading the system properties inside a privileged block.
I have found an existing method getSystemProperty in
org.apache.derby.iapi.services.property.PropertyUtil which does the job
of reading a system wide property inside a privileged block. The method
has the comment that this method can be used by a system that is not
running Cloudscape (I will change the Cloudscape reference to Derby in
my patch) and hence I think it should be safe for me to call this method
from the client driver even though the PropertyUtil class is in engine
code. I will also bring this issue of calling method across the
engine/client codeline in my patch for DERBY-1275 once I have a test
ready to test the system properties.
I don't think that's going to work, for a few reasons:
1) calling that method does more than lookup a system property, it also
looks for the properties in derby.properties, which is not valid for the
client.
2) A significant portion of the engine code (the monitor) will have to
be included in the client jar, thus increasing footprint.
3) Code sharing across client and engine is not supported due to the
classes being sealed by derby.jar and potential for class
incompatibilities when mixing different versions of client and engine.
The comment about the system not running Derby is misleading, but it's
there to allow the network server to get properties before the embedded
engine has booted.
I think you can just create an inline privileged block.
Dan.
