• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Unable to connect to jdbc OracleConnection

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was using com.ibm.ws.rsadapter.jdbc.wsjdbcconnection (which is part of IBM Websphere) for Oracle DB connectivity and now migrating code part of Tomcat webserver version 9.x I am getting java.lang.AbstractMethodError error message. I referred to the link dbconnection but still getting the error java.lang.classcastexception com.ibm.ws.rsadapter.jdbc.wsjdbcconnection incompatible with oracle.jdbc.oracleConnection.

The DB connection is established while trying to AQqueue.

Please help.



Error log
java.lang.AbstractMethodError
at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.unwrap(DelegatingConnection.java:811)
at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.unwrap(DelegatingConnection.java:811)
at com.Books.util.UtilitySvc.ConnectionPvtNativeAcquire(UtilitySvc.java:8)
at com.Books.util.UtilitySvc.execute(UtilitySvc.java:7)
at com.Books.util.UtilitySvc.ConnectionNativeAcquire(UtilitySvc.java:2)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1143)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1096)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:989)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4957)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5264)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:728)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1024)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1911)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
at org.apache.catalina.startup.HostConfig.deployWARS(HostConfig.java:825)
at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:475)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:948)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1388)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:921)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardService.startInternal(Standard Service.java:437)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:934)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:342)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
 
Saloon Keeper
Posts: 24499
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know what that Java code is, but it probably shouldn't have been used in WebSphere and it almost certainly shouldn't be used in Tomcat.

The standard method for accessing a database in a JEE webapp is via a Database Connection Pool. Tomcat comes with a standard pool manager (So does Webpshere, for that matter), although you can plug in alternative ones if you prefer. The application then acquires Connections by using JDNI to locate the desired pool's DatasSource interfae (an app can use multiple pools, if, for example, it's talking to more than one database). Once the Pool's DataSource has been located, it can be cached as it will not change for the life of the webapp. All database connections should be obtained via this interface and the Connections must be closed as quickly as possible after use.

Your stack trace seems to indicate that at least part of the Tomcat DBCP mechanism is being tapped into, but it's unclear what's going on. I don't think you included your complete stack trace, for one thing.

So we need more details. The JDBC URL and Oracle driver you are using would be a good start. So would the application code that's attempting to use JDBC. And a complete stack trace. Often the "Caused By" parts are the most important part.

In any event, under no circumstances should you be incorporating parts of WebSphere into a Tomcat webapp. Tomcat isn't designed for it.
 
mansree sreeal
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have placed the Websphere and the Tomcat migration code. For the Tomcat migration, I have made the code changes in the existing WebSphere class "UtilityConnectionService" in the Step3.

Also added the server.xml file.

I am getting java.lang.AbstractMethodError error message.

Please let me know whether I have to apply any changes in the server.xml file and could you provide suggestion for closing connection.

Step1
(Websphere DB Connection)



Step2 (Tomcat Migration)
Its working when I tried hard-code the DB connection in my "dequeMsg" method but when I tried to call the connection method from the Utility class it is failing as in Step3



Step3


Server.xml

 <Resource name="jdbc/bookds" auth="Container" type="javax.sql.DataSource"
              maxTotal="100" maxIdle="30" maxWaitMillis="10000" maxWait="10000" maxActive="100"
              username="test" password="test123" jdbcInterceptors="ConnectionState;StatementFinalizer"
              url="jdbc:oracle:thin:@localhost:1521:booksdb/" validationQuery="select 1 from dual" />



 
Tim Holloway
Saloon Keeper
Posts: 24499
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am still appalled. WHY is it necessary to use WebSphere or Oracle-specfic classes in your app? Even Oracle doesn't recommend that. All you need it this:

https://docs.oracle.com/cd/E19830-01/819-4725/abmdz/index.html

This is the exact same code to use under both WebSphere and Tomcat. And WebLogic and jetty. And so forth. It's the JEE standard.

Use that code to get a Connection, do your CRUD/stored-procedure operations, then close the Connection to automatically return it to the pool. That's it. As I said, you can store the results of the JNDI lookup as an Application Scope object refernce, but that's as much elaboration as anyone needs.



Beside that, you are apparently caching a JDBC connection and you should NEVER do that. You app can fail at unpredictable times. It may run fine for 20 years, but Murphy's Law says that when it does fail, it will fail at a time you find extremely regrettable.

Likewise, you should never attempt to obtain a Connection by brute force in a webapp. ALWAYS use a connection pool. It will reliably return connections - as long as you don't "lose" them by caching them - and it can be easily tuned without requiring changes to the webapp.

You are vastly over-complicating the app for no apparent gain and you're wasting time trying to violate JEE best practices.
 
mansree sreeal
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you, issue resolved
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic