db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4073) Creation/configuration of ClientXDataSource fails because of two setSsl methods
Date Thu, 26 Feb 2009 16:15:02 GMT

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

Rick Hillegas commented on DERBY-4073:

Hi Kristian,

I'm not an expert on Java Beans. It may be that the calling application falls back on ordinary
introspection to find the bean methods. There could be a bug in the the application or in
the Introspector class provided with the JRE. It may be possible to hide the setSsl(int) method
by providing BeanInfo classes in our public api packages. E.g., a ClientDataSource40BeanInfo
class which just exposes the getters and setters we really want to publish. There is some
explanation of this pattern in the BeanInfo javadoc and here: http://java.sun.com/docs/books/tutorial/javabeans/introspection/index.html
This may be an annoying amount of work which still doesn't fix the problem.

It seems to me that the Introspector or the calling application ought to be smart enough to
look for the setSsl() overload which matches the return type of getSsl(). It's not clear to
me that this is a Derby bug.

> 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:,,
>            Reporter: Kristian Waagan
> 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
>   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.

View raw message