You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Robert Bowen <sy...@yahoo.com> on 2005/06/28 09:39:54 UTC
Re: [DBCP] Problem initializing pool
Hello, thanks for the tip.
I was surfing around the API and didn't even see
BasicDataSource. I guess because it's in a different
package -- org.apache.commons.dbcp , whereas
SharedDataSource is in
org.apache.commons.dbcp.datasources.
Anyway, looking at the BasicDataSource I see that all
methods having to do with abandoned connections are
deprecated!
So is there a way to use DBCP/Pool and have it manage
your connections (log available and abandonded
connections, do garbage collection, etc.) I would
prefer not to have to put my own System.out.println()
or log.print() statements, especially since the
methods I would be calling (eg.
getAbandonedConnections() ) are deprecated!
Many thanks,
syg
--- Dirk Verbeeck <di...@pandora.be> wrote:
> Hi Robert,
>
> The configuration web page was written for the
> BasicDataSource
> connection pool implementation. The other pools do
> not support all
> params listed.
> In this case you are correct that
> SharedDataSourceFactory doesn't
> support the "abandoned" parameters (only
> BasicDataSource does).
>
> Regards
> Dirk
>
>
> Robert Bowen wrote:
> > Hello everyone.
> >
> > I am using DBCP (with Torque) for my J2EE app. I
> > believe I have a connection leak somewhere and I
> am
> > trying to find out where. When I try to initialize
> the
> > pool with parameters for dealing with and
> debugging
> > abandoned connections, I am getting errors with
> the
> > following params:
> >
> > Property: removeAbandoned, Value: true
> > Property: logAbandoned, Value: true
> > Property: removeAbandonedTimeout, Value: 300
> >
> > The error is always the same: "<param> value:
> <value>
> > is not supported by DataSource:
> >
>
org.apache.commons.dbcp.datasources.SharedPoolDataSource
> >
> > All three of these parameters appear on the DBCP
> > Configuration page
> >
>
(http://jakarta.apache.org/commons/dbcp/configuration.html).
> >
> >
> > I believe I have all the correct versions of all
> jars:
> >
> > commons-beanutils-1.7.0
> > commons-dbcp-1.2.1
> > commons-pool-1.2
> > commons-collections-3.0
> > commons-configuration-1.1
> >
> > ... but it doesn't want to work. The method that
> craps
> > out is in AbstractDataSourceFactory,
> setProperty().
> > Line 147:
> >
> > Class propertyType =
> PropertyUtils.getPropertyType(ds,
> > property);
> >
> > propertyType is always null.
> >
> > Can anyone give me a hand with this? It seems that
> the
> > SharedDataSourceFactory doesn't allow these
> params,
> > but according to the documentation it does. Any
> ideas?
> >
> > Many thanks,
> > syg
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [DBCP] Problem initializing pool
Posted by Dirk Verbeeck <di...@pandora.be>.
The reason why abandoned* methods are deprecated are explained in the
wiki: http://wiki.apache.org/jakarta-commons/DBCP
-- Dirk
Robert Bowen wrote:
> Hello, thanks for the tip.
>
> I was surfing around the API and didn't even see
> BasicDataSource. I guess because it's in a different
> package -- org.apache.commons.dbcp , whereas
> SharedDataSource is in
> org.apache.commons.dbcp.datasources.
>
> Anyway, looking at the BasicDataSource I see that all
> methods having to do with abandoned connections are
> deprecated!
>
> So is there a way to use DBCP/Pool and have it manage
> your connections (log available and abandonded
> connections, do garbage collection, etc.) I would
> prefer not to have to put my own System.out.println()
> or log.print() statements, especially since the
> methods I would be calling (eg.
> getAbandonedConnections() ) are deprecated!
>
> Many thanks,
> syg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [httpclient 3.0 rc1] - Protocol.registerProtocol
Posted by James Sangster <ja...@newswire.ca>.
Problem appears to have been resolved. When defining my new protocol
object I was assigning it as follows
new Protocol( "https", new EasySSLSocketFactory(), 443 );
when it should be
new Protocol( "myhttps", new EasySSLSocketFactory(), 443 );
Now when I register it as "myhttps", and pass in an "myhttps://" style URL,
everything works okay. I was thinking that I needed to have "https" in
order to make it be SSL, but forgot that the SSLContext is what concerns
itself about that.
james
-----Original Message-----
From: James Sangster [mailto:james.sangster@newswire.ca]
Sent: Tuesday, June 28, 2005 8:50 AM
To: 'Jakarta Commons Users List'
Subject: [httpclient 3.0 rc1] - Protocol.registerProtocol
Hello,
I started off developing my current project utilizing 3.0 rc1 of httpclient.
It's all working fine, and perhaps the error I'm getting is fixed in rc3,
but here goes.
I'm attempting to register a new protocol which allows self-signed
certificates to be accepted without saying "no trusted certificate found".
I've based this code off of the EasySSLSocketFactory (sp?). It works
beautifully when I register this with the string "https", as in
Protocol.registerProtocol( "https", myProtocol );
However... the trouble for me starts when I register this with a different
name, say, "myhttps", so as to avoid replacing the default https processing
as I still want that available for most cases. If I pass in a URL with
this prefix, it picks up the right ProtocolSocketFactory class (determined
through the debugger), but it's methods are never called (writing out some
System.out.println to test this). It seems that it's defaulting back to
the default Sun https checking code as I get the exception of "no trusted
certificate found".
Has anyone else encountered this problem? Once again, if the "https"
protocol is overwritten, it works fine, but if I register under anything
different then it defaults to the basic https checking which returns an
exception.
Any help or even shared experienced would be welcome.
james
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[httpclient 3.0 rc1] - Protocol.registerProtocol
Posted by James Sangster <ja...@newswire.ca>.
Hello,
I started off developing my current project utilizing 3.0 rc1 of httpclient.
It's all working fine, and perhaps the error I'm getting is fixed in rc3,
but here goes.
I'm attempting to register a new protocol which allows self-signed
certificates to be accepted without saying "no trusted certificate found".
I've based this code off of the EasySSLSocketFactory (sp?). It works
beautifully when I register this with the string "https", as in
Protocol.registerProtocol( "https", myProtocol );
However... the trouble for me starts when I register this with a different
name, say, "myhttps", so as to avoid replacing the default https processing
as I still want that available for most cases. If I pass in a URL with
this prefix, it picks up the right ProtocolSocketFactory class (determined
through the debugger), but it's methods are never called (writing out some
System.out.println to test this). It seems that it's defaulting back to
the default Sun https checking code as I get the exception of "no trusted
certificate found".
Has anyone else encountered this problem? Once again, if the "https"
protocol is overwritten, it works fine, but if I register under anything
different then it defaults to the basic https checking which returns an
exception.
Any help or even shared experienced would be welcome.
james
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org