db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Bergquist (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6350) Provide a rolling file implementation of derby.log
Date Fri, 20 Sep 2013 17:05:54 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773187#comment-13773187
] 

Brett Bergquist commented on DERBY-6350:
----------------------------------------

Probably not.  Those methods are invoked under the security policy of Derby and any file I/O
or accessing any system property is restricted by this security policy.  Creating and installing
a different security policy is no trivial task for most users and might not even be possible.


I tried going this route but in my case, Derby network server is being started by the Glassfish
application server.  Passing in a different security policy is not supported when Glassfish
starts Derby in this manner.  So I was left with changing the JVM security policy or having
the code within derby.jar so that it would have the same security policy of Derby.

Note that this request has come up before but it seems nobody has actually got it to work
at least not as far as I can find by searching.   The standard answer is "use derby.stream.error.method
or use derby.stream.error.field" but in fact this is complicated by the fact of the security
policy and is not easy to implement.

I think out of the box that Derby should support a rolling file log.  Derby is supposed to
be a zero administration database and having a log file grow without bounds is not zero administration,
at least not to me.

That being said, having Derby use the java.logger framework is desirable and in fact there
is a JIRA for that.   If it did use that framework directly (not by invoking an external piece
of code that will have the security policy problem that I mention), then the user could simply
configure the java.logger.FileHandler directly and all would be well.   But that seems much
more work in changing the Derby internals.


                
> Provide a rolling file implementation of derby.log
> --------------------------------------------------
>
>                 Key: DERBY-6350
>                 URL: https://issues.apache.org/jira/browse/DERBY-6350
>             Project: Derby
>          Issue Type: Improvement
>          Components: Miscellaneous
>            Reporter: Brett Bergquist
>            Priority: Minor
>              Labels: features
>         Attachments: rollingfilelog.patch.txt
>
>
> By default, derby.log grows without bounds if the derby.infolog.append property is set
to "true".   Setting this to "true" helps in a hands off production environment to ensure
that if Derby restarts, the derby.log which might contain important information is not lost.
 On the other hand, when set the "true" the derby.log grows without bounds.  This is problematic
in a long running system.  
> What is really needed is the ability to have a rolling derby.log file support where the
maximum file size and maximum number of files can be specified.  Derby has the ability to
configure the location of the log file (ie. derby.stream.error.file) and also two methods
of redirecting the error stream (.ie derby.stream.error.method and derby.stream.error.field).
 There is no standard implementation that supports a rolling derby.log however.
> This facility should be part of the core Derby system so that it works in both embedded
and network server models.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message