hg: jdk8/tl/jdk: 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety

[lance . andersen]

Changeset: 7a8978a5bb6e
Author:lancea
Date:  2012-12-12 20:57 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e

8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread 
Safety
Reviewed-by: naoto

! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialClob.java
! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java
! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java

Re: Infinite Loop in KeepAliveStream

[Martin Buchholz]

On Tue, Dec 11, 2012 at 7:40 AM, Chris Hegarty wrote:

> Hi Martin,
>
> Thank you for reporting this issue. I filed 8004863: "Infinite Loop in
> KeepAliveStream", to track it.
>
> I put together a small test to reproduce the problem (inline below). It is
> racey, but shows the problem most of the time on my machine.
>
> I tried your suggested patch, but found that there were cases where not
> enough data was being read off the stream, when it was being closed. This
> causes a problem for subsequent requests on that stream. The suggested
> patch below resolves this, and should also resolve the problem you are
> seeing ( patch against jdk8 ).
>
> Is this something that you want to run with, or would you prefer for me to
> get it into jdk8?
>
> diff -r fda257689786 src/share/classes/sun/net/www/**
> http/KeepAliveStream.java
> --- a/src/share/classes/sun/net/**www/http/KeepAliveStream.java   Mon Dec
> 10 10:52:11 2012 +0900
> +++ b/src/share/classes/sun/net/**www/http/KeepAliveStream.java   Tue Dec
> 11 15:30:50 2012 +
> @@ -83,10 +83,9 @@ class KeepAliveStream extends MeteredStr
>  if (expected > count) {
>  long nskip = expected - count;
>
>  if (nskip <= available()) {
> -long n = 0;
> -while (n < nskip) {
> -nskip = nskip - n;
> -n = skip(nskip);
> +while (nskip > 0) {
> +skip(nskip);
> +nskip = expected - count;
>  }
>

I'm still having a hard time understanding the code.  It looks to me like
the above still has issues if there is an asynchronous close in this loop.
 In that case skip() will make no progress and always return 0, and we will
continue to see nskip > 0.

How about (completely untested)

 if (expected > count) {
 long nskip = (long) (expected - count);
 if (nskip <= available()) {
-long n = 0;
-while (n < nskip) {
-nskip = nskip - n;
-n = skip(nskip);
-}
+do {} while ((nskip = (long) (expected - count)) > 0L
+ && skip(Math.min(nskip, available())) >
0L);
 } else if (expected <=
KeepAliveStreamCleaner.MAX_DATA_REMAINING && !hurried) {
 //put this KeepAliveStream on the queue so that the
data remaining
 //on the socket can be cleanup asyncronously.

hg: jdk8/tl/jdk: 8004235: Disable native JGSS provider on Mac

[weijun . wang]

Changeset: 5a2ab2c3f106
Author:weijun
Date:  2012-12-13 08:11 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106

8004235: Disable native JGSS provider on Mac
Reviewed-by: erikj, valeriep

! make/sun/security/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java

hg: jdk8/tl/jdk: 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)

[stuart . marks]

Changeset: 56fd5479a98f
Author:jgish
Date:  2012-12-12 15:37 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56fd5479a98f

8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete 
file (win)
Summary: Failure to delete test log file should be a warning instead of test 
failure
Reviewed-by: mduigou, smarks

! test/java/util/logging/CheckLockLocationTest.java

hg: jdk8/tl/langtools: 8004504: ListBuffer could reuse List.nil() as the sentinel element

[jonathan . gibbons]

Changeset: 170e486632d9
Author:jlahoda
Date:  2012-12-12 20:26 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/170e486632d9

8004504: ListBuffer could reuse List.nil() as the sentinel element
Summary: ListBuffer.last now points to the last elements with client data, or 
null if none.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/util/ListBuffer.java
+ test/tools/javac/util/list/ListBufferTest.java

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Chris Hegarty]

On 12 Dec 2012, at 19:01, Dmitry Samersoff  wrote:

> On 2012-12-12 22:29, Chris Hegarty wrote:
>> On 12/12/2012 18:15, Dmitry Samersoff wrote:
>>> Chris,
>>> 
>>> According to rfc2606 TLD .invalid is reserved for cases like this one,
>> 
>> Yes, I came across this, but there is nothing to stop an internal DNS
>> server from resolving .invalid domains. Anyway, may
>> "doesnot.exist.invalid" would be sufficient.
> 
> You can't prevent internal DNS from resolving anything without doing
> some heavy tricks, so I guess doesnot.exist.invalid and error message
> that clear states that DNS setup violates rfc2606 is sufficient.

Agreed. I'll add a debugging message with the results of a lookup of said name, 
to help diagnose future failures.

-Chris.

> 
> -Dmitry
> 
> 
>> 
>> -Chris.
>> 
>> 
>>> 
>>> So, it seems to me
>>> 
>>> domainame.invalid
>>> 
>>> is the best approach.
>>> 
>>> -Dmitry
>>> 
>>> 
>>> On 2012-12-12 20:15, Chris Hegarty wrote:
 
 On 12/12/2012 14:14, Alan Bateman wrote:
> 
>> -Chris.
> Would it be better if the test SocksServer had a list of knows that it
> always rejects? That might speed up the test too as it would avoid is
> trying to resolve host names or connect to hosts that don't exist.
 
 The UHE is thrown from the client socket connect(). The Server in this
 case doesn't ever receive the destination address or host name. It is
 simply replying to the initial/opening SOCKS handshake.
 
 The updated host name is still brittle ( if a .t TLD is ever registered!
 ). I don't have a better alternative.
 
 -Chris.
 
> 
> -Alan
> 
>>> 
>>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * Give Rabbit time, and he'll always get the answer

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Dmitry Samersoff]

On 2012-12-12 22:29, Chris Hegarty wrote:
> On 12/12/2012 18:15, Dmitry Samersoff wrote:
>> Chris,
>>
>> According to rfc2606 TLD .invalid is reserved for cases like this one,
> 
> Yes, I came across this, but there is nothing to stop an internal DNS
> server from resolving .invalid domains. Anyway, may
> "doesnot.exist.invalid" would be sufficient.

You can't prevent internal DNS from resolving anything without doing
some heavy tricks, so I guess doesnot.exist.invalid and error message
that clear states that DNS setup violates rfc2606 is sufficient.

-Dmitry


> 
> -Chris.
> 
> 
>>
>> So, it seems to me
>>
>>  domainame.invalid
>>
>> is the best approach.
>>
>> -Dmitry
>>
>>
>> On 2012-12-12 20:15, Chris Hegarty wrote:
>>>
>>> On 12/12/2012 14:14, Alan Bateman wrote:
 
> -Chris.
 Would it be better if the test SocksServer had a list of knows that it
 always rejects? That might speed up the test too as it would avoid is
 trying to resolve host names or connect to hosts that don't exist.
>>>
>>> The UHE is thrown from the client socket connect(). The Server in this
>>> case doesn't ever receive the destination address or host name. It is
>>> simply replying to the initial/opening SOCKS handshake.
>>>
>>> The updated host name is still brittle ( if a .t TLD is ever registered!
>>> ). I don't have a better alternative.
>>>
>>> -Chris.
>>>

 -Alan

>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Chris Hegarty]

On 12/12/2012 18:15, Dmitry Samersoff wrote:

Chris,

According to rfc2606 TLD .invalid is reserved for cases like this one,


Yes, I came across this, but there is nothing to stop an internal DNS 
server from resolving .invalid domains. Anyway, may 
"doesnot.exist.invalid" would be sufficient.


-Chris.




So, it seems to me

 domainame.invalid

is the best approach.

-Dmitry


On 2012-12-12 20:15, Chris Hegarty wrote:


On 12/12/2012 14:14, Alan Bateman wrote:



-Chris.

Would it be better if the test SocksServer had a list of knows that it
always rejects? That might speed up the test too as it would avoid is
trying to resolve host names or connect to hosts that don't exist.


The UHE is thrown from the client socket connect(). The Server in this
case doesn't ever receive the destination address or host name. It is
simply replying to the initial/opening SOCKS handshake.

The updated host name is still brittle ( if a .t TLD is ever registered!
). I don't have a better alternative.

-Chris.



-Alan

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Dmitry Samersoff]

Chris,

According to rfc2606 TLD .invalid is reserved for cases like this one,

So, it seems to me

domainame.invalid

is the best approach.

-Dmitry


On 2012-12-12 20:15, Chris Hegarty wrote:
> 
> On 12/12/2012 14:14, Alan Bateman wrote:
>> 
>>> -Chris.
>> Would it be better if the test SocksServer had a list of knows that it
>> always rejects? That might speed up the test too as it would avoid is
>> trying to resolve host names or connect to hosts that don't exist.
> 
> The UHE is thrown from the client socket connect(). The Server in this
> case doesn't ever receive the destination address or host name. It is
> simply replying to the initial/opening SOCKS handshake.
> 
> The updated host name is still brittle ( if a .t TLD is ever registered!
> ). I don't have a better alternative.
> 
> -Chris.
> 
>>
>> -Alan
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Alan Bateman]

On 12/12/2012 16:15, Chris Hegarty wrote:


On 12/12/2012 14:14, Alan Bateman wrote:



-Chris.

Would it be better if the test SocksServer had a list of knows that it
always rejects? That might speed up the test too as it would avoid is
trying to resolve host names or connect to hosts that don't exist.


The UHE is thrown from the client socket connect(). The Server in this 
case doesn't ever receive the destination address or host name. It is 
simply replying to the initial/opening SOCKS handshake.


The updated host name is still brittle ( if a .t TLD is ever 
registered! ). I don't have a better alternative.

Okay, I don't see a better alternative either.

-Alan

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

[Chris Hegarty]

Thank you Rob, I'm ok with this change.

-Chris.

On 12/12/2012 15:44, Rob McKenna wrote:

...the url would be helpful:
http://cr.openjdk.java.net/~robm/8000525/webrev.02/

-Rob
On 12/12/12 15:43, Rob McKenna wrote:

Hi Chris,

I guess I figured if the parse failed the cal.set wouldn't happen.
Still, no harm in moving the 1970 into the loop on the off chance
something else goes wrong.

I've updated the test too. Thanks for spotting that.

-Rob

On 10/12/12 16:59, Chris Hegarty wrote:

Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?

The test can simply throw Exception, rather can catching.

Otherwise, looks fine to me.

-Crhis.

On 06/12/2012 21:19, Rob McKenna wrote:

Hi folks,

According to HttpCookie.java:

"""
There are 3 http cookie specifications:

Netscape draft
RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/

HttpCookie class can accept all these 3 forms of syntax.
"""

According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:

"""
Netscape's original proposal defined an Expires header that took a date
value in a fixed-length variant format in place of Max-Age: Wdy,
DD-Mon-YY HH:MM:SS GMT
"""

Thats in the "Historical" section provided to allow for compatibility
with Netscape's implementation, which we also support: (as per
http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )

While we don't support the rfc explicitly, this change follows the
format specified in section 5.1.1 of rfc 6265:

"""
3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years
differently.
"""

The webrev is at:

http://cr.openjdk.java.net/~robm/8000525/webrev.01/


Note: The addition of setLenient(false) has required changes to two
existing testcases.

-Rob

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Chris Hegarty]

On 12/12/2012 14:14, Alan Bateman wrote:



-Chris.

Would it be better if the test SocksServer had a list of knows that it
always rejects? That might speed up the test too as it would avoid is
trying to resolve host names or connect to hosts that don't exist.


The UHE is thrown from the client socket connect(). The Server in this 
case doesn't ever receive the destination address or host name. It is 
simply replying to the initial/opening SOCKS handshake.


The updated host name is still brittle ( if a .t TLD is ever registered! 
). I don't have a better alternative.


-Chris.



-Alan

hg: jdk8/tl/jdk: 8004337: java/sql tests aren't run in test/Makefile

[rob . mckenna]

Changeset: 68374c6e65c1
Author:robm
Date:  2012-12-12 15:57 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68374c6e65c1

8004337: java/sql tests aren't run in test/Makefile
Reviewed-by: lancea, alanb

! test/Makefile

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

[Rob McKenna]

..the url would be helpful:
http://cr.openjdk.java.net/~robm/8000525/webrev.02/

-Rob
On 12/12/12 15:43, Rob McKenna wrote:

Hi Chris,

I guess I figured if the parse failed the cal.set wouldn't happen. 
Still, no harm in moving the 1970 into the loop on the off chance 
something else goes wrong.


I've updated the test too. Thanks for spotting that.

-Rob

On 10/12/12 16:59, Chris Hegarty wrote:

Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?

The test can simply throw Exception, rather can catching.

Otherwise, looks fine to me.

-Crhis.

On 06/12/2012 21:19, Rob McKenna wrote:

Hi folks,

According to HttpCookie.java:

"""
There are 3 http cookie specifications:

Netscape draft
RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/

HttpCookie class can accept all these 3 forms of syntax.
"""

According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:

"""
Netscape's original proposal defined an Expires header that took a date
value in a fixed-length variant format in place of Max-Age: Wdy,
DD-Mon-YY HH:MM:SS GMT
"""

Thats in the "Historical" section provided to allow for compatibility
with Netscape's implementation, which we also support: (as per
http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )

While we don't support the rfc explicitly, this change follows the
format specified in section 5.1.1 of rfc 6265:

"""
3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years 
differently.

"""

The webrev is at:

http://cr.openjdk.java.net/~robm/8000525/webrev.01/


Note: The addition of setLenient(false) has required changes to two
existing testcases.

-Rob

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

[Rob McKenna]

Hi Chris,

I guess I figured if the parse failed the cal.set wouldn't happen. 
Still, no harm in moving the 1970 into the loop on the off chance 
something else goes wrong.


I've updated the test too. Thanks for spotting that.

-Rob

On 10/12/12 16:59, Chris Hegarty wrote:

Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?

The test can simply throw Exception, rather can catching.

Otherwise, looks fine to me.

-Crhis.

On 06/12/2012 21:19, Rob McKenna wrote:

Hi folks,

According to HttpCookie.java:

"""
There are 3 http cookie specifications:

Netscape draft
RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/

HttpCookie class can accept all these 3 forms of syntax.
"""

According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:

"""
Netscape's original proposal defined an Expires header that took a date
value in a fixed-length variant format in place of Max-Age: Wdy,
DD-Mon-YY HH:MM:SS GMT
"""

Thats in the "Historical" section provided to allow for compatibility
with Netscape's implementation, which we also support: (as per
http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )

While we don't support the rfc explicitly, this change follows the
format specified in section 5.1.1 of rfc 6265:

"""
3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years 
differently.

"""

The webrev is at:

http://cr.openjdk.java.net/~robm/8000525/webrev.01/


Note: The addition of setLenient(false) has required changes to two
existing testcases.

-Rob

Re: RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Alan Bateman]

On 12/12/2012 14:02, Chris Hegarty wrote:


The test tries to connect (through a socks proxy on the localhost) to 
a domain that does not exist, "doesnt.exist.name". Guess what, someone 
just registered a domain with that name!


The test should be updated to use a domain name that really doesn't 
exist.


>: hg diff SocksV4Test.java
diff -r 806cf26e5063 test/java/net/Socks/SocksV4Test.java
--- a/test/java/net/Socks/SocksV4Test.java  Wed Dec 12 11:35:18 
2012 +
+++ b/test/java/net/Socks/SocksV4Test.java  Wed Dec 12 13:59:27 
2012 +

@@ -39,7 +39,7 @@ public class SocksV4Test {
 Proxy sp = new Proxy(Proxy.Type.SOCKS,
  new InetSocketAddress("localhost", 
srvr.getPort()));

 // Let's create an unresolved address
-InetSocketAddress ad = new 
InetSocketAddress("doesnt.exist.name", 1234);
+InetSocketAddress ad = new 
InetSocketAddress("d.o.e.s.not.e.x.i.s.t", 1234);

 try (Socket s = new Socket(sp)) {
 s.connect(ad, 1);
 } catch (UnknownHostException ex) {

-Chris.
Would it be better if the test SocksServer had a list of knows that it 
always rejects? That might speed up the test too as it would avoid is 
trying to resolve host names or connect to hosts that don't exist.


-Alan

RFR 8004925: java/net/Socks/SocksV4Test.java failing on all platforms

[Chris Hegarty]

The test tries to connect (through a socks proxy on the localhost) to a 
domain that does not exist, "doesnt.exist.name". Guess what, someone 
just registered a domain with that name!


The test should be updated to use a domain name that really doesn't exist.

>: hg diff SocksV4Test.java
diff -r 806cf26e5063 test/java/net/Socks/SocksV4Test.java
--- a/test/java/net/Socks/SocksV4Test.java  Wed Dec 12 11:35:18 2012 
+
+++ b/test/java/net/Socks/SocksV4Test.java  Wed Dec 12 13:59:27 2012 
+

@@ -39,7 +39,7 @@ public class SocksV4Test {
 Proxy sp = new Proxy(Proxy.Type.SOCKS,
  new InetSocketAddress("localhost", 
srvr.getPort()));

 // Let's create an unresolved address
-InetSocketAddress ad = new 
InetSocketAddress("doesnt.exist.name", 1234);
+InetSocketAddress ad = new 
InetSocketAddress("d.o.e.s.not.e.x.i.s.t", 1234);

 try (Socket s = new Socket(sp)) {
 s.connect(ad, 1);
 } catch (UnknownHostException ex) {

-Chris.

hg: jdk8/tl/jdk: 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener

[alan . bateman]

Changeset: 81640e75c7a7
Author:alanb
Date:  2012-12-12 13:03 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81640e75c7a7

8004874: Reduce dependency on java.beans to only 
add/removePropertyChangeListener
Reviewed-by: ksrini, mchung, dholmes

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/java/util/logging/LogManager.java

hg: jdk8/tl/jdk: 8004921: Trivial javadoc warnings in Base64

[chris . hegarty]

Changeset: 806cf26e5063
Author:chegar
Date:  2012-12-12 11:35 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/806cf26e5063

8004921: Trivial javadoc warnings in Base64
Reviewed-by: darcy

! src/share/classes/java/util/Base64.java

hg: jdk8/tl/jdk: 8004904: Makefile for ntlm

[weijun . wang]

Changeset: 12fba0974a9d
Author:weijun
Date:  2012-12-12 18:39 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fba0974a9d

8004904: Makefile for ntlm
Reviewed-by: erikj, chegar

! make/com/sun/security/Makefile
+ make/com/sun/security/ntlm/Makefile

Re: Code review: 8004904: Makefile for ntlm (was Re: com/sun/security/ntlm)

[Chris Hegarty]

Thank you Max, looks fine to me.

-Chris.

On 12/12/2012 03:32, Weijun Wang wrote:

Hi Chris/Mark

I've added a makefile, please take a look

http://cr.openjdk.java.net/~weijun/8004904/webrev.00/

*build-dev* guys, I guess this won't affect the new build style.

Thanks
Max


On 12/12/2012 09:28 AM, Weijun Wang wrote:



On 12/12/2012 01:50 AM, Chris Hegarty wrote:

Max,

Mark is looking to recompile com/sun/security/ntlm/Client.java during an
incremental build. I cannot find explicit targets for the
com/sun/security/ntlm files, are these compiled implicitly by reference
from other source? Is there a way of forcing these to be recompiled?

I admit, it is strange to me to find a complete package without some
kind of explicit reference in the makefiles, but maybe I just cannot
find it!


No, you cannot find it. There was no Makefile when those files were
added:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9be643e70f42

Thanks
Max




-Chris.

On 12/11/2012 05:36 PM, Mark Sheppard wrote:


Client.java

I modified files in other parts of jdk under sun.net
and these were rebuilt


regards
Mark
- Original Message -
From: chris.hega...@oracle.com
To: mark.shepp...@oracle.com
Sent: Tuesday, December 11, 2012 5:32:32 PM GMT +00:00 GMT Britain,
Ireland, Portugal
Subject: Re: com/sun/security/ntlm

What's the actual filename?

-Chris.

On 12/11/2012 05:15 PM, Mark Sheppard wrote:


Hi Chris,
I need some extra debug and modified a few files e.g.
com.sun.security.ntlm.Client.java. But the modified files
do not seem to have been rebuilt.

Can you think of anything obvious that I may have overlooked.

How can I force a rebuild of this component - partial build

regards
Mark