Re: A solution to the SSL customizing problem
От | Markus Schaber |
---|---|
Тема | Re: A solution to the SSL customizing problem |
Дата | |
Msg-id | 20041012123302.3ca76eb1@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | Re: A solution to the SSL customizing problem (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
Hi, Oliver, On Tue, 12 Oct 2004 21:23:58 +1300 Oliver Jowett <oliver@opencloud.com> wrote: > The situation I am thinking of is when you are configuring a DataSource > for use in a managed environment, e.g. appserver. The appserver knows > nothing about the driver it is using beyond the standard JDBC interfaces > (and perhaps not even that, if it's using a JCA wrapper). This breaks as > soon as you have a magic method that needs to be called on the driver to > configure SSL properties. There is no way to teach the appserver how to > do this without hardwiring dependencies on the PG way of doing things.. > which does not make for a very portable appserver! That's true. We were very happy to learn that the JBoss connection pooling uses wrappers that have a method to get the underlying original connection, so we could call addDataType() to add the postGIS classes. This left us with ugly code like: public static PGConnection unWrapPGConn(Connection conn) { PGConnection result = null; if (conn == null) { log.error("trying to unWrapPGConn(null)!"); return null; } if (conn instanceof PGConnection) { result = (PGConnection) conn; } else if (conn instanceof WrappedConnection) { WrappedConnection w = (WrappedConnection) conn; try { result = unWrapPGConn(w.getUnderlyingConnection()); } catch (SQLException e) { log.error("unWrapPGConn: Could not get underyling SQL connection!"); log.error(e.toString()); } } if (result == null) { log.warn("unWrapPGConn called with unknown connection type."); log.warn("given Connection Class is: " + conn.getClass().getPackage() + "." + conn.getClass().getName()); } return result; } So, you can see that this is a real world problem. Imagine we would need to have our App portable to other app servers - this would not only complicate the source above. We also would need to provide the appropriate classes in the other environments, so the classloader can find them for the instanceof call - this could imply strange licence issues. Additionally, we currently have different apps with different needs running in the same app server - so fine grained configurability is a must. We cannot provide a single static method because the apps are developed and deployed independently. FIN, Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
В списке pgsql-jdbc по дате отправления: