db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1229) sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission getProtectionDomain when db2jcc.jar is in same dir as the derby-jars
Date Thu, 04 May 2006 06:02:02 GMT
On 4/30/06, Bryan Pendleton <bpendleton@amberpoint.com> wrote:
> I was worried that adding a parameter to an existing message might
> introduce compatibility problems. I didn't have any specific
> reason for this worry; it's just a instinctive feeling that this
> is the sort of thing that might be a compatibility worry.

I don't think there's any compatibility concern for sysinfo in a mixed
client/server setup. Sysinfo information is not retrievable by the
client and is never called by the client. It is only available as a
diagnostic on the command line and through the
NetworkServerControl.getSysinfo() method. A copy of sysinfo is
packaged into derbynet.jar, and while it might be present elsewhere
through derby.jar, we only guarantee same versions of engine and
network server to work together anyway, so I think we might be ok.

> The only concrete thing I could find was on
> http://wiki.apache.org/db-derby/ForwardCompatibility
> where it says:
>  > Error messages: can not change text of existing error messages. Can add new error
> But also
>  > Error message text
>  >
>  > Private
>  >
>  > Note that this means canon-based tests can not make claims that a
>  > regression has occurred because the output from error messages has changed

I think this needs some clarification. Are error messages changeable
or not? It's not clear from this text.

> So, can we carry this discussion just a bit further? Is a change such as the
> following going to create a version compatibility problem, if I chase down
> every reference to the message in the current code and ensure that all those
> references pass the new parameter?

I think you'll find there's only one location where that particular
message (SIF03.C) is used. :-)

I think its ok to replace the message in this instance. But I
understand if you'd rather err on the side of caution. I'll leave it
up to you to make the decision. As for Kathey's other concern, making
the expected exceptions more user-friendly, I'm not sure what
direction to take.


View raw message