The recommended way to access a rowset is via the factory now.For whatever
reason the original authors chose not to provide a factory.
The connect() method has always been a method to be used internally by
JdbcRowSetRIImpl and Rave. There is no reason for a user of the API to ever
have to
As the comment noted, the connect method was made protected for Rave
requirement but it's not defined in JdbcRowSet and BaseRowSet. It's a
method specific to the RI and changing it to private is okay if they get
an JdbcRowSet instance by calling the rowset factory. Alan's question
prompts me
Hi Alan,
The connect method is used by the RI not the RowSet spec. It was made
protected for Rave.
Best
Lance
On Sep 6, 2012, at 1:21 PM, Alan Bateman wrote:
> Lance,
>
> I see you've just pushed this but one thing I didn't spot initially is that
> in the second webrev you changed the protec
Lance,
I see you've just pushed this but one thing I didn't spot initially is
that in the second webrev you changed the protected connect method to be
private. Is this a supported API and could this cause problems for JDBC
drivers that extend this?
-Alan
Hi Mandy,
Thank you also for the feedback along with Alan. I will push these back shortly
and also create a CR.
Best
Lance
On Sep 6, 2012, at 11:04 AM, Mandy Chung wrote:
> Lance,
>
> On 9/6/2012 5:40 AM, Lance Andersen - Oracle wrote:
>> Here is the updated webrev
>> http://cr.openjdk.java.n
Lance,
On 9/6/2012 5:40 AM, Lance Andersen - Oracle wrote:
Here is the updated webrev http://cr.openjdk.java.net/~lancea/7192302/webrev.01
It's good to see this change that jdbc rowset doesn't depend on java.beans.
This looks okay to me as you have explained why you remove the call to
connec
On 06/09/2012 14:45, Lance Andersen - Oracle wrote:
:
connect() is typically called to get a connection and it will validate
that there is a non-null Connection. I have unit tests which leverage
that constructor and run clean with that change.
I agree that commit(), rollback, etc should c
On Sep 6, 2012, at 9:31 AM, Alan Bateman wrote:
> On 06/09/2012 14:09, Lance Andersen - Oracle wrote:
>> :
>>>
>>> The latest webrev looks okay except that in one of the constructors you
>>> have removed a call to ensure that the connection is established, I'm not
>>> sure about the significan
On 06/09/2012 14:09, Lance Andersen - Oracle wrote:
:
The latest webrev looks okay except that in one of the constructors
you have removed a call to ensure that the connection is established,
I'm not sure about the significance of that.
This is not needed here and given I have already teste
Thank you for the comments Alan
On Sep 6, 2012, at 9:00 AM, Alan Bateman wrote:
> On 06/09/2012 13:40, Lance Andersen - Oracle wrote:
>> Here is the updated webrev
>> http://cr.openjdk.java.net/~lancea/7192302/webrev.01
>>
>> I know there is more clean-up that can be done to remove other Rave a
On 06/09/2012 13:40, Lance Andersen - Oracle wrote:
Here is the updated webrev http://cr.openjdk.java.net/~lancea/7192302/webrev.01
I know there is more clean-up that can be done to remove other Rave added code
(such as the removal of set/getPreparedStatement/Connection/ResultSet), I want
to k
Here is the updated webrev http://cr.openjdk.java.net/~lancea/7192302/webrev.01
I know there is more clean-up that can be done to remove other Rave added code
(such as the removal of set/getPreparedStatement/Connection/ResultSet), I want
to keep the focus to just removing PropertyChangeSupport.
On Sep 5, 2012, at 5:17 PM, Alan Bateman wrote:
> On 05/09/2012 22:04, Lance Andersen - Oracle wrote:
>> Hi all,
>>
>> Looking for a reviewer for the removal of PropertyChangeSupport from
>> JDBCRowSetImpl that was originally going to be used by the EOL Rave product.
>> As it is no longer nee
On 05/09/2012 22:04, Lance Andersen - Oracle wrote:
Hi all,
Looking for a reviewer for the removal of PropertyChangeSupport from
JDBCRowSetImpl that was originally going to be used by the EOL Rave product.
As it is no longer needed the code has been removed. The SQE and RowSet TCK
tests all
14 matches
Mail list logo
