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 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. On Sep 9, 2013, at 9:29 AM, Rick Hillegas <[email protected]> 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.getSystemProperty() > 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 ); > } > > } > >
