Your code will crash at the point where you are using the clob/blob object
without checking if it is null. For example, at the following statement:
result = aClob.getSubString(1L, (int) aClob.length());
Now, I have not checked what happens if the CLOB field is of zero length but
not null. If it is possible to have a zero-length CLOB field then we just
check for CLOB object being null and remove the check for its length.
----- Original Message -----
From: "Russell Smyth" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Friday, November 22, 2002 10:21 AM
Subject: RE: [PATCH]Re: null value for Blob/Clob causes NullPointerException
> I fail to se how your change is different, except that your change will
> leave the return value as null if the CLOB/BLOB length is 0 - which I
think
> is incorrect.
> If the db reports that the CLOB/BLOB is there but empty, then it is NOT
> null.
>
> my change returns null if the db reports null, and reports the value of
the
> BLOB/CLOB as reported by the db if not null.
>
> Your other changes I would have to look through the sources to see what
you
> intend. Diffs would be much easier to read here!
>
> -----Original Message-----
> From: Rajeev Kaul [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 11:11 AM
> To: OJB Users List
> Subject: Re: [PATCH]Re: null value for Blob/Clob causes
NullPointerException
>
>
> I do not think your patch addresses the problem of either CLOB or BLOB
> object being null. The fix that worked for me is shown below:
>
> case Types.CLOB :
> {
> java.sql.Clob aClob = rs.getClob(columnId);
> if (aClob != null && aClob.length() > 0)
> {
> result =
> aClob
> .getSubString(1L, (int) aClob.length())
> .toCharArray();
> }
> break;
> }
> case Types.BLOB :
> {
> java.sql.Blob aBlob = rs.getBlob(columnId);
> if (aBlob != null && aBlob.length() > 0)
> {
> result = aBlob.getBytes(1L, (int) aBlob.length());
> }
> break;
> }
>
>
> I had earlier submitted fixes for other CLOB issues. I am resending them
in
> case somebody finds them useful.
>
> To fix the problem, I made the following changes:
>
> 1. Modified ojbtest_schema.xml BLOB_TEST table to (the changes are shown
in
> Red).
>
> <table name="BLOB_TEST">
> <column name="ID" required="true" primaryKey="true" type="INTEGER"/>
> <column name="BLOB_VALUE_" type="BLOB"/>
> <column name="CLOB_VALUE_" type="CLOB"/>
> </table>
>
> 2. Modified the setObjectForStatement method of PlatformOracleImpl class
to
> write CLOB data as shown below:
>
>
> public void setObjectForStatement(PreparedStatement ps, int index, Object
> value, int sqlType) throws SQLException
>
> {
>
> if (((sqlType == Types.VARBINARY) ||
>
> (sqlType == Types.LONGVARBINARY) ||
>
> (sqlType == Types.BLOB)) &&
>
> (value instanceof byte[]))
>
> {
>
> byte buf[] = (byte[])value;
>
> ByteArrayInputStream inputStream = new ByteArrayInputStream(buf);
>
> changePreparedStatementResultSetType(ps);
>
> ps.setBinaryStream(index, inputStream, buf.length);
>
> }
>
> else if (sqlType == Types.CLOB)
>
> {
>
> CharArrayReader inputStream = new CharArrayReader((char[]) value);
>
> ps.setCharacterStream(index, inputStream, ((char[])value).length);
>
> }
>
> else if (value instanceof Double)
>
> {
>
> // workaround for the bug in Oracle thin driver
>
> ps.setDouble(index, ((Double) value).doubleValue());
>
> }
>
> else
>
> {
>
> super.setObjectForStatement(ps, index, value, sqlType);
>
> }
>
> }
>
> 3. In JdbcAccess class modified the getObjectFromColumn method for
CLOB/BLOB
> to what is shown at the top of this e-mail.
>
>
>
> The CLOB should return an object of type char[] to be consistent with
BLOBs
> returning objects of type byte[]. However, it is not mandatory to do so.
> We could leave this as is, and modify the CLOB fields in corresponding
> classes to be of type String. That is, for example, the ObjectWithBlob
> class will have to be modified to have the clob property defined as a
> String. But if we make the change shown above, you do not have to modify
> the ObjectWithBlob class - the clob property can remain as character
array.
>
>
> ----- Original Message -----
> From: "J. Russell Smyth" < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]>
> To: "OJB Users List" < <mailto:[EMAIL PROTECTED]>
> [EMAIL PROTECTED]>
> Sent: Thursday, November 21, 2002 9:51 PM
> Subject: [PATCH]Re: null value for Blob/Clob causes NullPointerException
>
>
> > We just happened to also run into that today.
> >
> > Attatched is a patch to fix, and a patch to the test case for blobs to
> > verify the fix. Unfortunately HSQLDB does not support the blob
> > functions, hence this test is commented out of AllTests, and I do not at
> > the moment have access to my other db's to run this test. However, it
> > should be good.
> >
> > On Thu, 2002-11-21 at 20:11, Michael Mogley wrote:
> > > I've just started experimenting with Ojb and seem to have run across a
> bug. Specifically, a Clob or Blob field whose value is undefined in the
db
> gives the following stack trace:
> > >
> > > java.lang.NullPointerException
> > > at
>
org.apache.ojb.broker.accesslayer.JdbcAccess.getObjectFromColumn(JdbcAccess.
> java:592)
> > > at
>
org.apache.ojb.broker.accesslayer.JdbcAccess.getObjectFromColumn(JdbcAccess.
> java:469)
> > > at
>
org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObjectArrayFrom(R
> owReaderDefaultImpl.java:141)
> > > at
>
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterat
> or.java:385)
> > > at
> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:203)
> > > at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
> rsistenceBrokerImpl.java:1117)
> > > at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
> rsistenceBrokerImpl.java:1239)
> > > at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
> rsistenceBrokerImpl.java:1265)
> > > at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
> rsistenceBrokerImpl.java:1252)
> > >
> > > Ojb attempts to perform operations on the Blob/Clob before checking to
> see if the returned value is null.
> > >
> > > Or am I missing something?
> > >
> > > Michael
> >
> >
>
>
>
>
> _____
>
>
>
>
> > --
> > To unsubscribe, e-mail: <
> <mailto:[EMAIL PROTECTED]>
> mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <
> <mailto:[EMAIL PROTECTED]>
> mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
