[
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
