Re: A solution to the SSL customizing problem

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