A small webrev:
http://cr.openjdk.java.net/~weijun/8003263/webrev.00/
The reason is that 8003120 added a new line
InputStream istream = (InputStream)resources.next();
but resources is already of type NamingEnumerationInputStream.
Building now shows
Hi ,
I didn't realize that rt.jar would miss before. The testcase is updated to
create a temp file as well as test the extract option. However, extract
testing will create a directory if it passes, I just deleted it in
testcase. Please take a look.
webrev:
On 12/11/2012 08:43, Weijun Wang wrote:
A small webrev:
http://cr.openjdk.java.net/~weijun/8003263/webrev.00/
The reason is that 8003120 added a new line
InputStream istream = (InputStream)resources.next();
but resources is already of type NamingEnumerationInputStream.
Building now
On 12/11/2012 09:08, Sean Chou wrote:
Hi ,
I didn't realize that rt.jar would miss before. The testcase is
updated to create a temp file as well as test the extract option.
However, extract testing will create a directory if it passes, I just
deleted it in testcase. Please take a look.
In fact, it looks like the resources object here is of type
InputStreamEnumeration (in
com/sun/naming/internal/VersionHelper12.java), with an
open-on-nextElement style. This means we can completely remove the while
(resources.hasMore()) block.
Lance and Andrew added for confirmation.
Thanks
Hi,
anyway you could use a one-liner:
resources.next().close();
-Ulf
Am 12.11.2012 11:22, schrieb Weijun Wang:
In fact, it looks like the resources object here is of type InputStreamEnumeration (in
com/sun/naming/internal/VersionHelper12.java), with an open-on-nextElement style. This
Which file(s) are you concerned about truncating/damaging? The code I'm
impacting is for creating a new lock file. Where is the potential for
truncating/damaging that you both are referring to?
Is this sufficient (plus the proper exception handling of course) ?
Hi Lance
Thanks for your quick response. Please find the bug info below.
The problem:
When CachedRowSetImpl.acceptChanges() is called, incorrect number of
conflicts, if any, is reported. The number of conflicts is the actual
number of existing rows in database, which is the size of
Hi Alan,
Here is the updated webrev:
http://cr.openjdk.java.net/~zhouyx/7201156/webrev.03/ .
On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman alan.bate...@oracle.comwrote:
On 12/11/2012 09:08, Sean Chou wrote:
Hi ,
I didn't realize that rt.jar would miss before. The testcase is updated
to
