pois é… eu tentei utilizar a mesma só que mudei pq dava o mesmo erro de cast:
algo ainda está sendo vinculado à outra biblioteca…
obs.: O tipo do meu dataSource que está no contexto da aplicação é do pacote javax.sql.DataSource, como eu mostrei antes. Mas acredito que isso não interfira no listener…
estou fazendo vários testes aqui pra ver se da certo… estou tentando de tudo, qualquer coisa eu volto a postar…
muito obrigado pela ajuda, Fernando…
Essa mensagem aqui de cast foi para caba - java.lang.ClassCastException: org.apache.commons.dbcp.BasicDataSource cannot be cast to org.apache.commons.dbcp.BasicDataSource Vc esta com jar’s duplicados de versões diferentes?
Posta ai sua context.xml:
vc por acaso mudou o factory?
vc ta usando commons mesmo ou outro provedor?
segue o context.xml
<Context reloadable="true">
<Resource auth="Container"
driverClassName="org.postgresql.Driver"
maxActive="50"
maxldle="15"
minIdle="5"
maxWait="20000"
name="jdbc/banco"
type="javax.sql.DataSource"
url="jdbc:postgresql://localhost:5432/banco"
username="postgres"
password="xxx"
validationQuery="select 1"
removeAbandoned="true"
removeAbandonedTimeout="60"/>
</Context>
como eu disse antes, o tipo está expecificado como javax.sql.DataSource mas não sei se interfere na conexão…
não mudei nenhum factory e na lib do tomcat está o commons-dbcp, tentei trocar e dá erro também… 
na lib do tomcat tem o commons-dbcp e o tomcat-dbcp (esta última coloquei no braço…)
se eu tirar a commons-dbcp não consigo nem a conexão com o banco…
Que coisa meu…
Qual versão do tomcat?
é a versão 6, e o SO é ubuntu server 10.04…
to tentando de tudo aqui mas sem sucesso… as conexões continuam lá e no log aquele erro de cast de um BasicDataSource para outro…
detalhe, eu importei essa lib org.apache.tomcat.dbcp.dbcp.BasicDataSource da lib do tomcat7 que eu tinha no meu micro pois nas libs do tomcat6 essa lib não existe, pelo menos no que eu tenho aqui… talvez por isso o erro de cast mas o estranho é que mesmo se eu colocar as libs idênticas no tomcat e na aplicação aquele erro de cast pra DataSources iguais ocorre…
O cast tem que parar de acontecer para o código funcionar e pool todo ser liberado.
No ambiente que eu montei aqui para fazer estes testes…instalei o tomcat 6 cruzão mesmo. Não retirei e não adicionou jar nenhum…
Seu erro de cast - java.lang.ClassCastException: org.apache.commons.dbcp.BasicDataSource cannot be cast to org.apache.commons.dbcp.BasicDataSource mostra que vc deve ter versões duplicadas no seu projeto…
Você provavelmente tem dois .jar do DBCP passeando por aí, um dentro
do tomcat e outro dentro da sua aplicação. …veja ai na sua lib e na lib do tomcat…
certo… mas eu preciso de um lib na aplicação para conseguir importar a classe org.apache.commons.dbcp.BasicDataSource e outra no lib do tomcat (que é a que veio padrão), elas precisam ser as mesmas, correto?
se eu colocar a mesma lib nos 2, continua dando erro de cast
se eu tirar do tomcat, ClassNotFound
e se eu tirar da aplicação vai compilar com erro (pois preciso da lib pra pode importar…)
Não…vc precisa de um jar só dentro do lib do tomcat!!!
Sua IDE deve importar automaticamente para dentro da aplicação todos os jars disponíveis dentro do tomcat.
Outra coisa não é org.apache.commons.dbcp.BasicDataSource !!!
É a essa aquiiiii - org.apache.tomcat.dbcp.dbcp.BasicDataSource
só que o projeto não é um projeto EE, é SE acessando um web service, então nao tenho as libs do tomcat importadas automaticamente…
e eu sei que vc passou a outra lib “org.apache.tomcat.dbcp.dbcp.BasicDataSource” só que nao achei nenhuma lib nativa do tomcat6 que contenha essa classe, apenas a outra que importei (do tomcat7), e mesmo eu importando essa lib tomcat-dbcp (que contém essa classe que vc falou) aí ocorre aquele erro de Cast…
ou seja, eu preciso de alguma lib que contenha esse caminho, pois nas do tomcat6 só contém a org.apache.commons.dbcp.BasicDataSource…
e por isso que terei que colocar a mesma lib na aplicação e no tomcat…
Estamos batendo cabeça a toa…claro que é projeto EE…não ta rodando no tomcat 6? não tem um web.xml? vc não gera um war? é projeto EE sim kkkkkkk
Esquece o consumidor de web services jse…ele não tem nada relacionado aqui…
Me fale do seu ambiente ai e projeto…
Vc não tem um projeto web que gerar um war? que é o projeto que vc expõe o web service?
Vc ta usando eclipse?
sim sim… é que tem um detalhe… é projeto web sim, na parte do web service…
utilizo o eclipse sim, mas não é pra versão EE (faço os xml no braço, e gero o .war com o ant)
por isso não tenho as libs do tomcat importadas automaticamente… pq como a programação em si do sistema (parte do cliente) é JSE, utilizamos o eclipse nessa versão e criamos o pouco que tem de ambiente web puramente no braço…
mas acabei de fazer uns testes aqui com o eclipse EE e não deu o erro de Cast, porém as conexões continuam lá…
detalhe: o web service tem uma thread que fica rodando pra limpar as sessões, e no undeploy informa que não foi possível pará-la, isso interfere em alguma coisa? (pois essa mensagem sempre foi informada no log…)
Dai fica difícil…isso ai é uma gambiarra na verdade…
Aconselho a vc fazer um projeto JEE , configurar um servidor web container…as libs serão importadas, vc pode depurar o listener e ver se a coisa realmente ta fazendo…e gerar o war via WTP mesmo.
Essa thread ai não interfere em nada…mas parece outra gambi sua…vc não precisa fazer isso…é usar o SESSION-TIME-OUT do container no seu web.xml
Eu tb tenho muitos projetos web services rodando JAX-WS dentro do tomat…funciona que é uma maravilha 
Bom, resolvido ja esta…só depende de vc ai…
ok… posso até fazer…
não sei se é uma gambiarra pois como eu disse nós só precisávamos do tomcat rodando por ter web service do outro lado (tanto que antes o pool era feito na própria aplicação, independente do web container)… nós não tínhamos nenhuma interface web ou algo do tipo pra trabalhar com JEE pois todas as views eram JSE… na parte web só tinha o web.xml (o context.xml só foi inserido quando tiramos o pool da aplicação e colocamos no tomcat)
enquanto eu escrevia esse post aqui, eu configurei o eclipse EE em outra máquina e vinculei o projeto com o tomcat, não deu mais nenhum erro no log do tomcat, como eu informei antes, porém as conexões não são removidas…
vou continuar tentando mas parece que não tem jeito daquelas conexões serem fechadas… já tentamos de tudo aqui…
novamente muito obrigado pela sua ajuda, Fernando.
[quote=erico_kl]ok… posso até fazer…
não sei se é uma gambiarra pois como eu disse nós só precisávamos do tomcat rodando por ter web service do outro lado (tanto que antes o pool era feito na própria aplicação, independente do web container)… nós não tínhamos nenhuma interface web ou algo do tipo pra trabalhar com JEE pois todas as views eram JSE… na parte web só tinha o web.xml (o context.xml só foi inserido quando tiramos o pool da aplicação e colocamos no tomcat)[/quote]
Não tem problema de não ter GUI web…um projeto web service é por natureza web!!! veja que é por isso q vc’s precisam do tomcat kkkkk…porque é um projeto web!! Só acho que vc estão fazendo na unha muita coisa que ja esta pronta no web container…
Tem jeito sim…depura o listener e veja se realmente esta invocando…veja as referências polimórficas do datasource…coloque log para garantir a execução…sei-la…eu não faço para vc pq não tenho postgree aqui…meu teste aqui foi feito com SQLServer…
Que tem jeito, tem…
realmente tentei aqui com um tomcat na máquina local, configurado junto com o Eclipse EE e deu certo, as conexões fecharam no undeploy!
é só ver um jeito agora de configurar em um tomcat remoto (pois testei e no tomcat remoto as conexões não foram limpadas)
mas já vi que resolve o problema mesmo… vou me adequar aqui com o ambiente web, pq tá mais que na hora kkk…
muito obrigado!
Que bom…demorou mas chegamos la.
Estamos ai para ajudar e servir.
Fica na paz.
só mais uma coisa, o seu ambiente que vc testou era linux? Aqui consegui fazer limpar só as conexões respectivas à ambiente windows. Quando rodo a mesma aplicação em um tomcat configurado num linux as conexões não são limpadas… embora não conste nenhum erro no log…
ah… quanto àquela Thread que limpa as sessões, ela é referente à autenticação do usuário no sistema, e não da própria sessão do tomcat (pois esta está configurada com o timeout sim…). Ou seja, o usuário se autentica via desktop e é criado uma thread pro seu web service e esta a cada acesso verifica a sua autenticidade e se o tempo dele (usuário no db) não se esgotou para então permitir ou não o consumo total do WS…
Pode não funcionar se seu ambiente de produção for diferente do desenvolvimento…outra versão do tomcat, versão do commons…
Aqui deu certo sim…
pois é… a versão do tomcat é a 6 para os 2 ambientes… só se eu copiasse as libs do tomcat do servidor de produção e substituisse pelas libs do tomcat de desenvolvimento… mas nunca antes precisei fazer isso pq tanto o servidor de produção quanto o de desenvolvimento (ambos remotos) rodam o mesmo tomcat… (sendo que tive que instalar um terceiro, na máquina local, pra poder adicionar as libs, como vc falou…)