Skip to main content

[PATCH] JDBCLoginService - honour "server" argument to authenticate(...)

3 replies [Last post]
ringerc
Offline
Joined: 2008-06-08

I found JDBCLoginService somewhat painful to use with the four-argument static dialog constructor from JXLoginPane. JDBCLoginService ignores the "server" argument to authenticate(...), so the user's selection of the server to use has no effect.

Right now, JXLoginPane.showLoginFrame(...., serverList) and JXLoginPane.showLoginDialog(...., serverList) seem to be less than useful. The server list is displayed, but setServer(...) isn't called on the LoginService before calling authenticate(...), and at least the JDBCLoginService ignores the "server" argument to authenticate(...). There also doesn't seem to be any way for the calling code to retrieve the user's selected server, whether using showLoginFrame or showLoginDialog.

JAASLoginService calls setServer(...) if passed a non-null server argument to authenticate(...), so JDBCLoginService and JAASLoginService are also inconsistent in behaviour.

A workaround is to produce an anonymous subclass of the login service (eg JDBCLoginService) which overrides authenticate(...) to call setServer(...):

<br />
final JDBCLoginService loginService = new JDBCLoginService(props.getDriverString(), props.getUrlList().firstElement()) {<br />
            @Override<br />
            public boolean authenticate(String name, char[] password, String server) throws Exception {<br />
                setServer(server);<br />
                return super.authenticate(name, password, server);<br />
            }<br />
        };<br />

... but that shouldn't be necessary.

Instead, do you think the JDBCLoginService should change its current server to that provided in the "server" argument, if non-null? If so, how does it know whether to treat it as a JNDI context or a JDBC URL?

I've attached a patch with a proposed solution. The patch removes the jndiContext member variable of JDBCLoginService, since this information was already stored in the "server" property of the parent login service. It replaces it with a boolean flag "usingJNDI" (exposed as a property) which explicitly controls whether the JDBCLoginService will use JDBC's DriverManager or will use JNDI to obtain connections. Thus, there's no confusion about what the "server" argument to authenticate() means. The patch calls setServer(...) from authenticate(...) if the server argument is non-null, before attempting to authenticate via a DriverManager-obtained connection or via JNDI as appropriate.

Behaviour for existing users should not change EXCEPT that the "server" and redundant "url" properties are updated by the setServer(...) call to authenticate() when the server argument is non-null.

Patch:

http://www.postnewspapers.com.au/~craig/weblinks/JDBCLoginService.diff

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11

ringerc,

personally, I'm a profound agnostic to everything related to backend ;-) So assume you have hit something here - would you please file an issue in the swingx issue tracker (with a link back to this thread) so the experts in the swingx team won't forget?

Thanks
Jeanette

ringerc
Offline
Joined: 2008-06-08
kleopatra
Offline
Joined: 2003-06-11

thanks!

Jeanette