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 derby.properties.
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. Brett -----Original Message----- From: Rick Hillegas [mailto:[email protected]] Sent: Thursday, September 12, 2013 10:39 AM To: [email protected] 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: http://people.apache.org/committer-index.html > 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. Thanks, -Rick > 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.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 ); >> } >> >> } >> >> > >
