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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
