db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: Is there some way an external class can find where derby.system.home points to
Date Wed, 18 Sep 2013 13:51:25 GMT
Rick, I started work on getting this ready for a patch submission but I have run into one problem.
 If I put the code in the tools packages, I don't know how to get a hold of properties of

Katherine Marsden wrote:

"You can read the system property derby.system.home and if not set use the property user.dir.
That said, I think it would be good to incorporate this functionality into the core product
and then the properties could go into derby.properties.  It seems to me there was a Jira issue
for this, but I can't find it right now."

So there is conflicting requirements I guess.  If this is part of derbytools.jar it really
can't get access to derby.properties but if we want the logging configuration properties to
be in derby.properties, then this cannot really be in derbytools.jar.

Looking for some advice here.


-----Original Message-----
From: Rick Hillegas [mailto:rick.hillegas@oracle.com] 
Sent: Thursday, September 12, 2013 10:39 AM
To: derby-dev@db.apache.org
Subject: Re: Is there some way an external class can find where derby.system.home points to

On 9/10/13 5:42 PM, Bergquist, Brett wrote:
> Sorry for taking so long to get back.   Thanks for the suggestion, Rick, I will give
it a try.
>   I did make my code properly perform file I/O and property access as well in privilege
blocks, so hopefully if I can provided it back to Derby, it should also be pretty well on
the way.  I found that these are required anyways as soon as I try to do file I/O (write to
the rolling log file) so I had to somehow change my security policy.   For now, the quickest
and cleanest that I could do for my installation was to put my DerbyUtil.jar in the JRE "ext"
directory (so it gets on the classpath) and will also give it the permissions needed without
altering a security policy.
> It is my hope that this could become part of the standard derby offering.   Right now,
i have the code in my own packages but I supposed that I should put them within the package
structure of Derby if this were to be so.
> So a question, in this implementation, I have two classes: one that provides a rolling
output stream that can be configured (and borrowed heavily on the java.util.FileHandler code)
and takes similar properties to configure the number of files, the size, appending, etc. 
 This is readily reusable for any rolling output stream.   The second is the one that is a
configurator class that creates an instance of the rolling output stream and provides the
static method that Derby needs to hook into retrieving this stream to be used instead of derby.log
Thanks for offering to donate this code, Brett. In case anyone is wondering, Brett's ICLA
is on file: 
> So If i were to refactor the code to be in the derby package hierarchy, what would you
think would be good/proper derby packages for these two classes?  This way, it might be easier
to provide a patch that could be reviewed and provide the files.
Sounds like this would appear in Derby's public API. The only API package which looks relevant
to me is org.apache.derby.tools. That would be a commitment to put the new code in derbytools.jar.
That might be the right place for it, particularly if we think that this logger could be used
by client-side code too.

> On Sep 9, 2013, at 9:29 AM, Rick Hillegas<rick.hillegas@oracle.com>  wrote:
>> On 9/6/13 5:35 AM, Bergquist, Brett wrote:
>>> I finally broke down and wrote RollingFileStream which provides (and borrows)
most of the functionality of java.logger.FileHandler to provide a rolling file stream.   Having
derby.log grow forever on long running systems is just not acceptable anymore ;)   Realistically,
I would like to provide this back to the derby community somehow as I found many requests
for such a feature while searching and many references to using "derby.stream.error.method"
or "derby.stream.error.field", but no good implementation of such.
>>> I built a DerbyUtil.jar which the class along with a configurator class which
can read a "derbylog.properties" file for configuration information.   I would like to locate
this file at the same place as "derby.properties" so the configurator needs to find out what
"derby.system.home" is set to.   Because of the default security policy installed by the network
server and because my DerbyUtil.jar is separate, it cannot access the property.   Create and
installing my own security policy is also a bit of a pain as the network server is started
by Glassfish and there really is not much opportunity to pass startup parameters.
>>> So is there someway to locate the location that  "derby.ssystem.home" is pointing
to in my class that is being invoke by "derby.stream.error.field"?
>>> How about a proposal that "derby.stream.error.field" can point to a static method
that can take 0 or 1 parameters and if one parameter, it is passed the value of "derby.system.home"
as a String.  This seems to be a simple change and could easily be accommodated by first using
reflection to find the method that takes 0 parameters and if not found, retry with finding
the method that takes one string parameter?
>>> Brett
>> Hi Brett,
>> You could use
>> org.apache.derby.iapi.services.property.PropertyUtil.getSystemPropert
>> y() to get the value of derby.system.home. That method will wrap the 
>> call to
>> System.getProperty() in a privileged block which runs with the 
>> privileges granted to the Derby engine jar. PropertyUtil isn't part 
>> of the Derby public api so this isn't technically a supported 
>> approach and we reserve the right to change the behavior of that 
>> class. However, that class doesn't change much so you can probably 
>> get away with this.  At the end of this message there's an example 
>> dummy error logger which uses PropertyUtil to lookup the value of 
>> derby.system.home. To test this out, boot the network server with this setting:
>>    -Dderby.stream.error.field=DummyErrorLogger.DEL
>> Hope this helps,
>> -Rick
>> import java.io.OutputStream;
>> import java.io.OutputStreamWriter;
>> import java.io.Writer;
>> import org.apache.derby.iapi.services.property.PropertyUtil;
>> public class DummyErrorLogger   extends OutputStreamWriter
>> {
>>      public  static  final   Writer  DEL = makeErrorLogger();
>>      public  DummyErrorLogger( OutputStream os )
>>      {
>>          super( os );
>>      }
>>      private  static  DummyErrorLogger    makeErrorLogger()
>>      {
>>          System.out.println( "Making the error logger..." );
>>          String  derbySystemHome = PropertyUtil.getSystemProperty( 
>> "derby.system.home" );
>>          System.out.println( "derbySystemHome = " + derbySystemHome 
>> );
>>          return new DummyErrorLogger( System.out );
>>      }
>> }

View raw message