Hi Amita

Another question I have is regarding EasyMock dependency, looks like you are
using the in DASImpl to create a context ? Or is that a piece of test that
got left inside DASImpl by mistake ?

--
Luciano Resende
http://people.apache.org/~lresende

On 1/8/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.prepareStatement where 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 <http://people.apache.org/%7Elresende>


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

Reply via email to