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.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 );
}
}
