CODEWITHSUNDEEP
javatomcatjpatomcat6jndi
Udo Held
Udo Held

Reputation: 12548

AbstractMethodError setBinaryStream on Tomcat

I'm developing a JPA application backed by hibernate on tomcat. We are using Spring and AOP as well. The database is a DB2 9.7 community edition. We are using a Spring JNDI lookup to retrieve the datasource from tomcat.

It's a tomcat 6.0.26 that comes bundled with the Liferay portal. Updating the tomcat is not an option, as we have problems upgrading Liferay to a newer version / bundle.

The persisting is running fine in our test cases, however with tomcat we get the following exception. The application works well until the point where I want to store the attachment.

Caused by: java.lang.AbstractMethodError: org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.setBinaryStream(ILjava/io/InputStream;J)V
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81)
at $Proxy432.setBinaryStream(Unknown Source)
at org.hibernate.type.descriptor.sql.BlobTypeDescriptor$4$1.doBind(BlobTypeDescriptor.java:163)

Looking at other questions Why do I get java.lang.AbstractMethodError when trying to load a blob in the db? The problem seems to that a jdbc3 driver instead of a jdbc4 driver is used. However I made sure that we have the correct DB2 driver version "db2jcc4.jar 4.14.113". The same driver works for our testcase.

When one searches elsewhere the problem is that setBinaryStream is called with long instead of int, but as I don't call anything directly I cannot change that.

The entity in question:

@Table( name = "ATTACHMENT")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(namespace = "somenamespace", name = "Attachment")
public class Attachment implements Serializable {
   private static final long serialVersionUID = 1L;

    /**
    */
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   @Column(name = "ID", nullable = false)
   @Basic(fetch = FetchType.EAGER)
   @Id
   @XmlElement
   Integer id;
   /**
    */

   @Column(name = "ATTACHMENT", nullable = false)
   @Basic(fetch = FetchType.EAGER)
   @Lob
   @XmlElement
   byte[] attachment;

      .. getters/setters and other properties
}

What can be done to circumvent the problem so that it saves the entity like in the test case?

Update: Probably not the db driver itself but the tomcat connections pool isn't JDBC4 compliant. The Tomcat 6 documentation says "DBCP 1.3 provides support for JDBC 3.0.". Exchanging it with plain dbcp seems to be no good idea, when looking at tomcat-dbcp vs commons-dbcp.

Upvotes: 1

Views: 3439

Answers (1)

Udo Held
Udo Held

Reputation: 12548

After a while I found a solution.

I downloaded tomcat 7 and copied over the tomcat-dbcp.

The tomcat-dbcp 7 contains dbcp 1.4 and provides JDBC 4.0 support.

Upvotes: 1

Related Questions