Hi Luciano,
Yes, it was for DB2 driver db2java.jar - the file bldlevel in this jar
specifies the version as
D:/wsdb/db2nt_v81ga/s021011. This jar comes with DB2 8.1.0.24.
It does not support the syntax connection.prepareStatement(String, int).
Also, a few questions on the same line, do we specify some restrictions in
any doc
about the driver compliance to any particular jdbc standard like jdbc 3.0etc.?
And, now with this JIRA - I just want to confirm that, it is responsibility
of the end user
to include the required driver jar in the classpath, and we do not need to
modify pom /
classpath for the same. Is this right?
Regards,
Amita
On 1/9/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
Hi Amita
I got curious about the changes inside ConnectionImpl. Looks like you
have introduced a error handling inside the
ConnectionImpl.prepareStatementwhere you try to prepare the statement
with the option to return generated
keys, but if an abstract method error is found, you then resubmit it
without
this option. Where you trying to overcome some JDBC driver limitation ?
public PreparedStatement prepareStatement(String queryString, String[]
returnKeys) throws SQLException {
if (this.logger.isDebugEnabled()) {
this.logger.debug("Preparing Statement: " + queryString);
}
if (useGetGeneratedKeys) {
//JIRA-948 start - check for AbstractMethodError
PreparedStatement preparedStatement = null;
try{
preparedStatement = connection.prepareStatement
(queryString,
Statement.RETURN_GENERATED_KEYS);
return preparedStatement;
}catch(java.lang.AbstractMethodError e){
//System.out.println("following exception route in
prepareStatement()");
preparedStatement = connection.prepareStatement
(queryString);
return preparedStatement;
}
//JIRA-948 end
} else if (returnKeys.length > 0) {
return connection.prepareStatement(queryString, returnKeys);
}
return connection.prepareStatement(queryString);
}
I'm still looking into the patch, and will let you know if I have further
questions
--
Luciano Resende
http://people.apache.org/~lresende
On 1/5/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> Hi All,
> Please check the attachments to JIRA-948 on 5th Jan (it includes code
> changes in rdb-das
> and a sample to test the same). Please let me know your feedback.
>
> Also, the sample tests for new config xsd element introduced for all the
3
> dbs. Is it good
> to add a test case to rdb-das doing the same or it will be just
duplicate
> effort?
>
> Regards,
> Amita
>
> On 12/20/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > Have got the code changes working for Derby and testing for DB2 and
> MySQL.
> > config.xsd will have
> > <xsd:complexType name="ConnectionInfo">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0"
> > name="ConnectionProperties"
> > type="config:ConnectionProperties"/>
> > </xsd:sequence>
> > <xsd:attribute name="dataSource" type="xsd:string"/>
> > <xsd:attribute name="managedtx" type="xsd:boolean"
default="true"/>
> > <xsd:attribute name="contextAvailable" type="xsd:boolean"
> > default="true"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="ConnectionProperties">
> > <xsd:attribute name="dataSourceClass" type="xsd:string"/>
> > <xsd:attribute name="databaseLocation" type="xsd:string"/>
> > <xsd:attribute name="user" type="xsd:string"/>
> > <xsd:attribute name="password" type="xsd:string"/>
> > <xsd:attribute name="key" type="xsd:string"
> > default="193-155-248-97-234-56-100-241"/>
> > <xsd:attribute name="databaseName" type="xsd:string"/>
> > <xsd:attribute name="charset" type="xsd:string"
> default="US-ASCII"/>
> > <xsd:attribute name="loginTimeout" type="xsd:int" default="-1"/>
> > </xsd:complexType>
> >
> > With this, change the old xml samples will work as is. i.e. old
> > samples where the connection is assumed to be available from managed
> > env. like tomcat, will work without modification.
> >
> > For J2SE env.e.g. xml section will be like
> > <!--<ConnectionInfo dataSource="java:comp/env/jdbc/dastest"/>-->
> > <ConnectionInfo dataSource="java:comp/env/jdbc/dastest"
> > contextAvailable="false">
> > <ConnectionProperties
> > dataSourceClass="
> > org.apache.derby.jdbc.EmbeddedDataSource"
> > databaseLocation="c:/dastest"
> > user="guest"
> > password="210-144-194-150-116-115-179-0"
> > key="193-155-248-97-234-56-100-241"
> > databaseName="dastest"
> > loginTimeout="600000">
> > </ConnectionProperties>
> > </ConnectionInfo>
> >
> > Will attach the code modifications to JIRA after finishing the testing
> > in 1-2 days.
> >
> > Regards,
> > Amita
> >
> > On 12/7/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
> > > I agree.. With only milestone builds out this shouldn't be a big
> > > issue. In this particular case, the impact should be limited as it
> > > will only affect those who were using the DAS in a J2EE environment.
> > >
> > > Brent
> > >
> > > On 12/7/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> > > > IMO, at this early stage, we should continue to improve and
simplify
> > all
> > > > user APIs even when this requires breaking changes.
> > > > How do others feel about this?
> > > > Thanks.
> > > > --
> > > > Kevin
> > > >
> > > >
> > > > Luciano Resende wrote:
> > > >
> > > > > Brent and Amita,
> > > > >
> > > > > If we make these updates and connectionInfo becomes XML
elements
> > > rather
> > > > > then XML Attributes, would this break backward compatibility and
> > make
> > > all
> > > > > applications to have to update all DAS XML Config, is this
right
> ?
> > If
> > > > > this
> > > > > is the case, is this acceptable ?
> > > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
