You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/01/05 11:47:08 UTC
Re: [DAS]Approach for JIRA-948
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 <am...@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: [DAS]Approach for JIRA-948
Posted by Luciano Resende <lu...@gmail.com>.
One more, related to Licensing.
In your patch, SymetricEncryptionUtil.java source is basically a copy from
the WebSite http://www.informit.com/guides/content.asp?g=java&seqNum=31&rl=1
Looking at the website legal information
http://www.informit.com/about/legal.asp?rl=1, the rights of the code
published is property of the "Pearson Education" and we won't have rights to
publish it at Apache Tuscany. We are going to need a clean implementation of
the encrypt/decrypt functionality in order to apply the patch.
--
Luciano Resende
http://people.apache.org/~lresende
On 1/8/07, Luciano Resende <lu...@gmail.com> wrote:
>
> 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 <http://people.apache.org/%7Elresende>
>
> On 1/8/07, Luciano Resende <lu...@gmail.com> 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 < amita.vadhavkar@gmail.com> 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 < amita.vadhavkar@gmail.com > 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 < brenthdaniel@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: [DAS]Approach for JIRA-948
Posted by Luciano Resende <lu...@gmail.com>.
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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <amita.vadhavkar@gmail.com > 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 < brenthdaniel@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
> >
>
Re: [DAS]Approach for JIRA-948
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi All,
Please see the latest patch on Jan 18 and associated Note and give your
comments about changes, corrections etc.
Regards,
Amita
On 1/10/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Hi,
> Regarding the ecryption util, am trying for a clean new util.
>
> For JNDI context provider - used EasyMock as a sample. It can be replaced
> by sun's fscontext or jboss's jnp. Jboss mentions its free use. Please let
> me know if there can be any licensing implications in using sun or jboss.
>
> Also, at present EasyMock is working fine in the current patch code as a
> context provider.
> As it's also open source, can it be used as is or need to be replaced with
> another JNDI
> provider like jboss jnp?
>
> Regards,
> Amita
>
> On 1/9/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Amita wrote :
> >
> > >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.?
> >
> > I'll do some research on this...
> >
> > >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?
> >
> > Yes, the user should add the jar to classpath, for CompanyWeb we
> > describe on
> > the readme.html what steps are needed in order to get derby jar file and
> > put
> > on the right location in a TC environment.
> >
> > Also, could you please give some feedback on the next two questions as
> > well
> > ?
> >
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12524.html
> >
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12536.html
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> > On 1/8/07, Amita Vadhavkar <amita.vadhavkar@gmail.com > wrote:
> > >
> > > 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 <lu...@gmail.com> 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 < amita.vadhavkar@gmail.com> 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 < amita.vadhavkar@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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:
> > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: [DAS]Approach for JIRA-948
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
Regarding the ecryption util, am trying for a clean new util.
For JNDI context provider - used EasyMock as a sample. It can be replaced
by sun's fscontext or jboss's jnp. Jboss mentions its free use. Please let
me know if there can be any licensing implications in using sun or jboss.
Also, at present EasyMock is working fine in the current patch code as a
context provider.
As it's also open source, can it be used as is or need to be replaced with
another JNDI
provider like jboss jnp?
Regards,
Amita
On 1/9/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Amita wrote :
>
> >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.?
>
> I'll do some research on this...
>
> >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?
>
> Yes, the user should add the jar to classpath, for CompanyWeb we describe
> on
> the readme.html what steps are needed in order to get derby jar file and
> put
> on the right location in a TC environment.
>
> Also, could you please give some feedback on the next two questions as
> well
> ?
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12524.html
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12536.html
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
> On 1/8/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <am...@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: [DAS]Approach for JIRA-948
Posted by Luciano Resende <lu...@gmail.com>.
Amita wrote :
>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.?
I'll do some research on this...
>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?
Yes, the user should add the jar to classpath, for CompanyWeb we describe on
the readme.html what steps are needed in order to get derby jar file and put
on the right location in a TC environment.
Also, could you please give some feedback on the next two questions as well
?
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12524.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12536.html
--
Luciano Resende
http://people.apache.org/~lresende
On 1/8/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <am...@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: [DAS]Approach for JIRA-948
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <am...@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
> >
>
>
Re: [DAS]Approach for JIRA-948
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> 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 <am...@gmail.com> 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 <br...@gmail.com> 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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>