[jetty-users] Strange connection pool behavior in Jetty 7.5.4

[Daniel Murnane <danieltm@xxxxxxxxx>]

I'm using the Codehaus Hightide distribution with c3p0-0.9.1.2. On 7.5.4, when I start jetty, it tries to initialize the c3p0 pool several times, adding another of the config options I have set each time it tries. It looks like it eventually works on the last try, but this causes several "java.sql.SQLException: Access denied for user 'user'@'host' (using password: NO)" exceptions in the logs. It also looks like it picks up the maximum connection pool size after it opens a connection to the database server. Jetty 7.5.1 works like I would expect, but I haven't tried 7.5.2 or 7.5.3 to see how they behave yet.

I'm configuring the connection pool through the webapp context. The relevant section is as follows:
  <New id="foo" class="org.eclipse.jetty.plus.jndi.Resource">
    <Arg></Arg>
    <Arg>java:foo</Arg>
    <Arg>
      <New class="com.mchange.v2.c3p0.ComboPooledDataSource">
        <Set name="driverClass">com.mysql.jdbc.Driver</Set>
        <Set name="jdbcUrl">jdbc:mysql://foo:3306/foodb</Set>
        <Set name="user">user</Set>
        <Set name="password">password</Set>
        <Set name="maxPoolSize">5</Set>
        <Set name="minPoolSize">2</Set>
      </New>
    </Arg>
  </New>

The first message logged looks like this:
16:06:43,408 INFO  [AbstractPoolBackedDataSource] Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -> foo, debugUnreturnedConnectionStackTraces -> false, description -> null, driverClass -> null, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> foo, idleConnectionTestPeriod -> 0, initialPoolSize -> 3, jdbcUrl -> null, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 0, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 15, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 3, numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0, preferredTestQuery -> null, properties -> {}, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false ]

The next message defines driverClass and jdbcUrl, then User is defined, then password, then maxpoolsize, and finally minpoolsize. Everything defined in a previous message stays defined, so the last message has everything defined properly.

Any ideas why this is behaving strangely?

Thanks,
-Dan