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":
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.