[
https://issues.apache.org/jira/browse/DERBY-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773021#comment-13773021
]
Brett Bergquist commented on DERBY-6350:
----------------------------------------
One general comment. My goal was to touch as little of the Derby code as
possible to minimize the risk of introducing this. In fact, besides
Property.java where the property constants are defined, there is no other code
changes to Derby core. It uses the existing ability to redirect the error log.
If the goal of this should be changed to make this more seamless, I don't have
a problem, but again that was not my goal.
I would have liked to have provided this as a standalone extension but a couple
of things get in the way. The logging is done by the Derby core and it was
desirable to locate the rolling log files in the same location as the existing
derby.log. But there is no readily available way of determining the location
of derby.log using the derby.stream.error.method or derby.stream.error.field
facilities provided; neither of these mechanisms provide any context to use to
lookup this location. The second problem is if this is indeed provided in a
separate JAR, then the security policy comes into play. The invoking code of
derby.stream.error.method contains a security policy in effect and being able
to read system properties and write files becomes restricted by that policy.
Have to change or provide a new security policy just to get rolling log files
seemed to complex and cumbersome, so I made the decision that this
functionality needs to be as part of the core of Derby so that the same
security policy can be used.
Kathey Marsden indicated that having the properties of configuring the rolling
file in "derby.properties" was preferable to having another properties file and
I agree so this also made the decision to incorporate this into Derby core.
As for renaming the property from "rollingfile" to "rollingFile", I have no
issue with this.
As for "derby.stream.error=rollingFile", this will imply that the normal
"derby.stream.error.method" and "derby.stream.error.field" cannot be used or we
need to document the conflict resolution if they are. I understand that using
"derby.stream.error=rollingFile" seems easier but it does make for more
documentation and code changes in Derby core. I don't know if the benefit is
worth the trade off.
As for the "derby.stream.error.rollingFile.limit" and
"derby.steam.error.rollingFile.count" and
"derby.stream.error.rollingFile.pattern", these are directly from the
"java.logger.FileHandler":
http://docs.oracle.com/javase/7/docs/api/java/util/logging/FileHandler.html
with the addition of the "%d" pattern addition to represent
"derby.system.home". The semantics of the file size limit and file count limit
are the same as "java.logger.FileHandler" and are pretty straightforward and
known to the Java community I think, so my feeling is that keeping this as
similar to that is a benefit and the documentation of these can be directly
lifted from that javadoc.
Doing the changes that you suggest are possible but also seem to conflict with
what is already provided by Derby. For example, the "derby.stream.error.file"
specifies the location (and filename) of the output of the error stream and
when this is set then the "derby.stream.error.field" and
'derby.stream.error.method" are ignored. Right there is a conflict that is
documented. The "derby.stream.error.method" also has a conflict resolution
with "derby.stream.error.field" that is documented.
It seems to me that adding another "derby.stream.error" property will require
updating the conflict resolution and documentation of the existing properties
which is more work that I think is worth.
Basically we are providing the user with a complete implementation that can be
plugged into Derby using the standard mechanism that already exists namely the
"derby.stream.error.method" with understanding that the implementation is part
of Derby core and that the implementation has additional properties that can be
configured through "derby.properties".
My feeling is the simplicity of the integration using the mechanism already
provided by Derby, the limit of risk in the integration into Derby core, along
with the familiarity of configuration parameters that nearly match those of the
"java.logger.FileHandler", and the requirement of just adding to the
documentation on configuring this facility without changing or altering the
existing documentation of the existing facilities is pretty important.
I do agree with your comment on exposing and "impl" package publicly however.
It does not "feel right", however, I could not find another place that "felt
right" either especially with the goal of using the "derby.stream.error.method"
mechanism.
> 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
