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]
> >
> >
>
