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