Bug 777995 (SOA-522) - The SQL listener is not usable with most of databases
Summary: The SQL listener is not usable with most of databases
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-522
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: JBossESB
Version: 4.2 CP01
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.2 CP02
Assignee: Mark Little
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-23 09:50 UTC by Jiri Pechanec
Modified: 2008-10-20 11:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-13 10:56:20 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 778375 0 urgent CLOSED The SQL listener is not usable with most of databases 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker JBESB-2116 0 None None None Never
Red Hat Issue Tracker SOA-522 0 None None None Never

Internal Links: 778375

Description Jiri Pechanec 2008-04-23 09:50:58 UTC
Date of First Response: 2008-06-11 07:14:25
project_key: SOA

See JBESB-1690

Comment 1 Jiri Pechanec 2008-04-23 09:51:05 UTC
Link: Added: This issue depends JBESB-1690


Comment 2 Jiri Pechanec 2008-06-11 09:45:44 UTC
Verified in CR1

Comment 3 Jiri Pechanec 2008-06-11 10:11:08 UTC
The solution works for CLOB types but not from BLOB types. According to code both types should be supported.
Results from PostgreSQL
2008-06-11 12:06:35,363 DEBUG [org.jboss.internal.soa.esb.couriers.SqlTableCourier] SQL exception during deliver
org.postgresql.util.PSQLException: ERROR: column "string_data_column" is of type bytea but expression is of type character varying
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1531)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1313)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
        at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:278)
        at org.jboss.internal.soa.esb.couriers.SqlTableCourier.deliver(SqlTableCourier.java:158)
        at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:188)
        at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:525)
        at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:447)
        at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:316)
        at org.jboss.soa.esb.client.ServiceInvoker.deliverAsync(ServiceInvoker.java:225)
        at org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl.redeliver(DBMessageStoreImpl.java:394)
        at org.jboss.soa.esb.actions.MessageRedeliverer.process(MessageRedeliverer.java:74)
        at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
        at org.jboss.soa.esb.listeners.ScheduleListener.onSchedule(ScheduleListener.java:121)
        at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:218)
        at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

Probably the stream approcha should be used instead of setObject

Comment 4 Kevin Conner 2008-06-11 11:14:25 UTC
I guess postgres handles this differently as both were tested.

I will create a new issue to cover the postgres case as it may be seen on other DBs.

Comment 5 Kevin Conner 2008-06-11 11:22:38 UTC
Link: Added: This issue depends JBESB-1805


Comment 6 Kevin Conner 2008-06-11 11:23:06 UTC
JBESB-1805 has been created to cover the new work

Comment 7 Jiri Pechanec 2008-06-19 12:15:48 UTC
Link: Added: This issue depends JBESB-1833


Comment 8 Jiri Pechanec 2008-06-19 13:48:55 UTC
Link: Added: This issue depends JBESB-1834


Comment 9 nwallace 2008-09-25 19:51:10 UTC
Link: Added: This issue related SOA-858


Comment 10 Jiri Pechanec 2008-10-13 10:50:14 UTC
There is still one ptifall with the implementation
                        if (type == Types.BLOB) {
                            final Blob blob = RS.getBlob(iCurr) ;
                            row.put(sCol, StreamUtils.readStreamString(blob.getBinaryStream(), "UTF-8"));
                        } else if (type == Types.CLOB) {
                            final Clob clob = RS.getClob(iCurr) ;
                            row.put(sCol, StreamUtils.readReader(clob.getCharacterStream()));
                        } else {
                            row.put(sCol, RS.getObject(iCurr));
                        }
The problem is that on some databases (e.g. Oracle) if the column contains null value, then the cals RS.getXlob(iCurr) return null and the next line causes NPE. There should be something like
if (blob == null) {
row.put(sCol, null);
}
else {
                            row.put(sCol, StreamUtils.readStreamString(blob.getBinaryStream(), "UTF-8"));
}

Comment 11 Kevin Conner 2008-10-13 10:54:41 UTC
Please create a new issue and relate it to this one.

Comment 12 Mark Little 2008-10-13 11:15:02 UTC
Link: Added: This issue related JBESB-2116


Comment 13 Mark Little 2008-10-20 11:22:31 UTC
Link: Added: This issue is a dependency of JBESB-2135



Note You need to log in before you can comment on or make changes to this bug.