Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <700343676.1236250436190.JavaMail.jira@brutus>
Date: Thu, 5 Mar 2009 02:53:56 -0800 (PST)
From: "Kristian Waagan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4073) Creation/configuration of
 ClientXDataSource fails because of two setSsl methods
In-Reply-To: <4334054.1235652422113.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kristian Waagan commented on DERBY-4073:
----------------------------------------

That is possible.
To use the method, the user would have to use either brute force or inspect the source code to determine the valid values. To my knowledge, setSsl(int) isn't documented anywhere. Leaning on the statement Rick made, the valid values for setSsl(String) could be extrapolated from the documentation of connection URL attributes.
I think we should write a release note for this fix.

Note that if we make Derby throw an exception if the user specifies a property that has its own setter method in connectionAttributes, we definitely have to write a release note.

> Creation/configuration of ClientXDataSource fails because of two setSsl methods
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-4073
>                 URL: https://issues.apache.org/jira/browse/DERBY-4073
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.3.1, 10.4.2.1, 10.5.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: derby-4073-1a-add_docs_and_remove_setSsl_int.diff
>
>
> Applications using reflection (and JavaBean conventions) have problems configuring the Derby client data sources.
> Depending on how things are done, the user may or may not see the problems.
> For instance, some applications obtain all valid data source properties and list them with their default settings. In the case of SSL, this will be "Ssl" with value "off". When the application is trying to call setSsl("off") through reflection it may invoke setSsl(int) instead of setSsl(String), failing because "off" cannot be converted to an integer. In some implementations both methods will be invoked.
> There are two ways to look at this, and I don't know which one is correct:
>   o the reflection code of the third-party applications using Derby isn't written well enough.
>   o Derby is to blame for the problem by providing two setSsl-methods.
> I don't know if providing overloading setters violates the JavaBean spec, or any other relevant spec we should follow.
> The easiest technical solution is to rename one of the methods or possibly making one of them private. Both of these will break existing applications using that method to configure a Derby client data source.
> Is doing this, and providing a release note, sufficient?
> Does anyone see any other solutions?
> It should be noted that in some applications, it is impossible to configure ClientConnectionPoolDataSource or ClientXADataSource to use SSL. The reasons are the problem described here and DERBY-4067. One typical class of software with this problem is application servers. A workaround is to avoid setting the SSL property, which isn't doable if you need SSL of course...
> A related issue is whether it should be allowed to set the SSL property both through the setter method(s) and as a connection attribute.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.