PreparedStatement.clearParameters is abstract

[Jochen]

Hi…

when trying to deploy to Wildly 9 I get the following exception stacktrace (abbreviated):

 

Error during transaction: java.lang.AbstractMethodError: Method immutant/transactions/jdbc$prepared_statement$reify__527.clearParameters()V is abstract

at immutant.transactions.jdbc$prepared_statement$reify__527.clearParameters(jdbc.clj)

…

Indeed, clearParameters seems not to be in the reify.

Outside Wildly I use another datasource definition, so it works there. BTW: I toggle between the datasources on startup using immutant.util/in-container?, is this a good approach?

Ciao

…Jochen

[Jim Crossley]

Hi Jochen,

Would you mind including the full stack trace and the snippet of code that toggles between your datasources, please?

We may in fact need to implement more calls in the reify's, but I'd like to replicate what you're doing locally to see it first. I don't see the call to clearParameters when I use the WF9 datasource.

Thanks!
Jim

[Jochen]

Hi Jim…

yes, I can send the stack trace, but it has to be later as I unfortunately have to leave now. What I can say now is that the statement.clearParameters is called by our code when using the statement delivered by the connection produced by the datasource.

Please let me know if this is enough info, otherwise I will happily provide more info and stack traces.

Ciao

…Jochen

[Jim Crossley]

Nah, don't worry about it. We only implemented enough methods on those to satisfy the [org.clojure/java.jdbc] library either insider or outside WildFly. I wasn't thinking they'd be used outside of that, but that was probably short-sighted on my part. :)

I'll file an issue to implement the whole interface. Thanks for the report!

Jim

[Jochen]

Cool, looking forward to it :-). 

Maybe this is indeed an interesting use case, we use the same jdbc code in "real" javaland Wildfly and Immutant.

Ciao

...Jochen

[Jim Crossley]

Hi Jochen,

Incremental build 663 (and higher) should contain a fix for you. To try it, you'll need to add a repo to your project.clj. See http://immutant.org/builds/2x/

Let us know if that works, and we'll include it in the next official release. Reference: https://issues.jboss.org/browse/IMMUTANT-590

Thanks again!

Jim

[Jochen]

Hi Jim...

thanks a lot! sorry for the late reply, I am on another project right now, I will test it ASAP and let you know (hopefully this week).

Ciao

...Jochen

 

[Jochen]

Hi Jim…

yes you've got it. Tried with build 685 and it works fine now. Thank you for the fix!

Ciao

…Jochen

P.S. There was an exception on deployment, but it is probably unrelated and did not seem to hamper functionality:

2015-11-11 09:13:21,005 INFO  [org.hornetq.core.server] (rapidamicro.war-worker-0) HQ221003: trying to deploy queue jms.queue.DLQ

2015-11-11 09:13:21,009 INFO  [org.hornetq.core.server] (rapidamicro.war-worker-0) HQ221003: trying to deploy queue jms.queue.ExpiryQueue

2015-11-11 09:13:21,065 ERROR [org.hornetq.core.server] (rapidamicro.war-worker-0) HQ224000: Failure in initialization: 

java.net.BindException: Address already in use

at sun.nio.ch.Net.bind0(Native Method)

at sun.nio.ch.Net.bind(Net.java:437)

at sun.nio.ch.Net.bind(Net.java:429)

at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)

at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:102)

at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:479)

at io.netty.channel.DefaultChannelPipeline$HeadHandler.bind(DefaultChannelPipeline.java:1000)

at io.netty.channel.DefaultChannelHandlerContext.invokeBind(DefaultChannelHandlerContext.java:457)

at io.netty.channel.DefaultChannelHandlerContext.bind(DefaultChannelHandlerContext.java:442)

at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:842)

at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:194)

at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:331)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)

at java.lang.Thread.run(Thread.java:745)

[Jim Crossley]

Great! The fix will be in the next release, hopefully within a week or two.

Not sure what's going on with the BindException, but if we can help, holler.

Jim