From Alan.Bateman at Sun.COM  Wed Oct 10 13:49:04 2007
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 10 Oct 2007 21:49:04 +0100
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
Message-ID: <470D3AC0.5090006@sun.com>


It may be used in the Windows implementation - the networking group will 
know.
-------------- next part --------------
An embedded message was scrubbed...
From: Roman Kennke <roman at kennke.org>
Subject: PlainSocketImpl.socketGetOption1() ?
Date: Wed, 10 Oct 2007 22:42:21 +0200
Size: 5319
Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20071010/0acde0c8/attachment.nws 

From Christopher.Hegarty at Sun.COM  Wed Oct 10 14:36:35 2007
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems)
Date: Wed, 10 Oct 2007 22:36:35 +0100
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <470D3AC0.5090006@sun.com>
References: <470D3AC0.5090006@sun.com>
Message-ID: <470D45E3.4080300@sun.com>

Hi Roman,

This method was added as part of the changes for 4868820: "IPv6 support 
for Windows XP and 2003 server", back in 1.5. But I cannot see anywhere 
that it is called, or as you said even implemented, even when it was 
originally added. I suspect that it was left over from some redesign 
when adding the IPv6 support.

I actually noticed this went adding support for the dual TCP/IP stack in 
vista, DualStackPlainSocketImpl, and even added a comment to remind me 
to remove it!

I will file a new bug against this to have it removed and update this 
mailing list with the bug number when I have it.

-Chris.

Alan Bateman wrote:
> 
> It may be used in the Windows implementation - the networking group will 
> know.
> 
> ------------------------------------------------------------------------
> 
> Subject:
> PlainSocketImpl.socketGetOption1() ?
> From:
> Roman Kennke <roman at kennke.org>
> Date:
> Wed, 10 Oct 2007 22:42:21 +0200
> To:
> Core-Libs-Dev <core-libs-dev at openjdk.java.net>
> 
> To:
> Core-Libs-Dev <core-libs-dev at openjdk.java.net>
> 
> 
> Hi list,
> 
> The PlainSocketImpl family of classes have a method socketGetOption1(),
> which is required by the AbstractPlainSocketImpl class, and implemented
> by the subclasses, but apparently never used. There isn't even a native
> implementation for the native method in PlainSocketImpl. Could this
> method be removed, or is there another story behind this?
> 
> /Roman
> 


From Michael.McMahon at Sun.COM  Thu Oct 11 04:25:51 2007
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Thu, 11 Oct 2007 12:25:51 +0100
Subject: UrlEncodedQueryString CCC request
Message-ID: <470E083F.8000205@sun.com>

We have been asked by the CCC to go back and reconsider the design of 
the proposed
UrlEncodedQueryString class/API and to consider aligning it with the 
URIBuilder class
that has been proposed in JSR311. Also, the particular concern expressed 
by the CCC
is that we possibly restricted the scope of the class too much.

What I think we would like to achieve (for Java SE) is a general purpose 
URI builder that is not
specifically tied to any particular type of web application.

When Richard initially proposed the UrlEncodedQueryString, it was more 
like a URIBuilder
but our concern (which I think is still valid) is that a Java SE class 
for constructing URIs
must be solely based on defined standards (the URI rfcs), rather than on 
ad-hoc (albeit commonly used)
conventions in the world of web applications. Specifically, I don't 
think we can impose
any additional structure on URIs that is not explicitly specified in the 
relevant URIs.
But if other people have a different view on this, I'm interested to 
discuss it.

A reference for the JSR311 class is at
https://jsr311.dev.java.net/nonav/javadoc/index.html

and Paul Sandoz's blog entry talking about it is at
http://blogs.sun.com/sandoz/entry/building_uris

The javadoc for the proposed UrlEncodedQueryString is attached in a zip file

Thanks,
Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: docs.zip
Type: application/octet-stream
Size: 25965 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20071011/8f215521/docs.zip 

From roman.kennke at aicas.com  Thu Oct 11 10:56:00 2007
From: roman.kennke at aicas.com (Roman Kennke)
Date: Thu, 11 Oct 2007 19:56:00 +0200
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <470D45E3.4080300@sun.com>
References: <470D3AC0.5090006@sun.com>  <470D45E3.4080300@sun.com>
Message-ID: <1192125360.2826.10.camel@mercury>

Hi Christopher,

> This method was added as part of the changes for 4868820: "IPv6 support 
> for Windows XP and 2003 server", back in 1.5. But I cannot see anywhere 
> that it is called, or as you said even implemented, even when it was 
> originally added. I suspect that it was left over from some redesign 
> when adding the IPv6 support.
> 
> I actually noticed this went adding support for the dual TCP/IP stack in 
> vista, DualStackPlainSocketImpl, and even added a comment to remind me 
> to remove it!

The methods java.net.NetworkInterface.getSubnet0() and
java.net.NetworkInterface.getBroadcast0() seem to be affected by the
same problem. May I propose the attached patch to fix?

/Roman
 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-sockets.txt
Type: text/x-patch
Size: 4133 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20071011/c0a7aa89/openjdk-sockets.txt 

From roman.kennke at aicas.com  Thu Oct 11 12:04:23 2007
From: roman.kennke at aicas.com (Roman Kennke)
Date: Thu, 11 Oct 2007 21:04:23 +0200
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <1192125360.2826.10.camel@mercury>
References: <470D3AC0.5090006@sun.com>  <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury>
Message-ID: <1192129463.2826.25.camel@mercury>

Hi again,

> May I propose the attached patch to fix?

For some reason, the original patch contained a typo (don't ask. Stupid
IDEs). Here's the corrected one.

/Roman
 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-sockets.txt
Type: text/x-patch
Size: 3928 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20071011/8ec6ba21/openjdk-sockets.txt 

From sarel at botha.us  Thu Oct 11 12:57:48 2007
From: sarel at botha.us (Sarel Botha)
Date: Thu, 11 Oct 2007 15:57:48 -0400
Subject: Strange problem w/ RMI HTTP to CGI socket factory
Message-ID: <470E803C.5050603@botha.us>

Hi All,

This problem seems strange to me and I don't know where to look to 
resolve it.

The RMIHttpToCGISocketFactory class is working well for me. I call 
RMISocketFactory.setSocketFactory(new RMIHttpToCGISocketFactory ()), 
then Naming.lookup() and all is well. However, I need to customize this 
class a little, so I got a copy of the source code for the package 
sun.rmi.transport.proxy, then renamed the package for these classes to 
sun.rmi.transport.proxy2 (also tried openjdk.sun.rmi.transport.proxy).

If I try to use the same class in this package I get this error when it 
tries to establish the RMI connection:
java.rmi.ConnectIOException: error during JRMP connection establishment; 
nested exception is:
        java.io.IOException: attempt to write on HttpSendSocket after 
request has been sent
        at 
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286)

What's happening is that the underlying RMI code is calling 
HttpSendOutputStream.write() and passing only 7 bytes. This is 
immediately sent to the server which responds with only about 18 bytes. 
Then, it tries to call write() again, which should never happen, so it 
throws the exception you see above.

When it works (using the socket factory that ships with JRE6) it first 
sends 58 bytes and the server responds with 217 bytes. You can also see 
the name of the RMI service in the request and the server response 
contains the name of the stub and the IP where the service is running.

It seems like the underlying implementation is treating this socket 
factory totally differently from the one it ships with.

Must the code be compiled with different switches maybe? Must the socket 
factory be registered somewhere? Any pointers would be appreciated.

Thanks,
Sarel


From richard at kennardconsulting.com  Thu Oct 11 16:17:01 2007
From: richard at kennardconsulting.com (Richard Kennard)
Date: Fri, 12 Oct 2007 09:17:01 +1000
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <470E083F.8000205@sun.com>
References: <470E083F.8000205@sun.com>
Message-ID: <470EAEED.7000300@kennardconsulting.com>

Michael (Paul? Marc?),

Looking at the JSR311 URIBuilder, and with respect to Mark (Reinhold)'s 
concerns, I actually don't think there is much of an overlap between 
them. Specifically:

1) javax.ws.rs.core.UriBuilder seems primarily concerned with building 
URIs by leveraging UriTemplates
2) java.net.UrlEncodedQueryString seems primarily concerned with 
modelling a query string

While 1) is useful for building URIs in a JSR311-specific way, 2) is 
useful for parsing and retrieving and modifying query parameters (eg. 
not solely a builder)

So while an implementation of JSR311 may want to use 
java.net.UrlEncodedQueryString internally, I don't see how the two 
classes could effectively merge, because UriBuilder isn't concerned with 
parsing and retrieving and modifying, and UrlEncodedQueryString isn't 
concerned with UriTemplates.

Regards,

Richard.

Michael McMahon wrote:
> We have been asked by the CCC to go back and reconsider the design of 
> the proposed
> UrlEncodedQueryString class/API and to consider aligning it with the 
> URIBuilder class
> that has been proposed in JSR311. Also, the particular concern 
> expressed by the CCC
> is that we possibly restricted the scope of the class too much.
>
> What I think we would like to achieve (for Java SE) is a general 
> purpose URI builder that is not
> specifically tied to any particular type of web application.
>
> When Richard initially proposed the UrlEncodedQueryString, it was more 
> like a URIBuilder
> but our concern (which I think is still valid) is that a Java SE class 
> for constructing URIs
> must be solely based on defined standards (the URI rfcs), rather than 
> on ad-hoc (albeit commonly used)
> conventions in the world of web applications. Specifically, I don't 
> think we can impose
> any additional structure on URIs that is not explicitly specified in 
> the relevant URIs.
> But if other people have a different view on this, I'm interested to 
> discuss it.
>
> A reference for the JSR311 class is at
> https://jsr311.dev.java.net/nonav/javadoc/index.html
>
> and Paul Sandoz's blog entry talking about it is at
> http://blogs.sun.com/sandoz/entry/building_uris
>
> The javadoc for the proposed UrlEncodedQueryString is attached in a 
> zip file
>
> Thanks,
> Michael.


-- 
Richard Kennard | Principal | Kennard Consulting
0402 629 952
http://www.kennardconsulting.com



From Christopher.Hegarty at Sun.COM  Fri Oct 12 01:22:00 2007
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 12 Oct 2007 09:22:00 +0100
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <1192129463.2826.25.camel@mercury>
References: <470D3AC0.5090006@sun.com> <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury> <1192129463.2826.25.camel@mercury>
Message-ID: <470F2EA8.5030606@sun.com>

Hi Roman,

The bug I filed against this issue is 6615656. It has not reached our 
external bug interface yet, but should do so in the next few days. When 
it does it will be reachable at:
   http://bugs.sun.com/view_bug.do?bug_id=6615656

On another note, thanks you for the contribution. I have not yet 
reviewed it, but I am sure it will prove to be very useful.

As I am sure you are aware Sun requires all contributers to complete a
Contributor Agreement before any contributions can be accepted. It is 
quite straight forward and should not take any time at all to complete. 
You can find a link to the agreement as well as an FAQ and details of 
how to submit it at the following location:
   https://sca.dev.java.net/CA_signatories.htm

When you complete this I would be very happy to work with you to get 
your contribution integrated.

Regards,
-Chris.

Roman Kennke wrote:
> Hi again,
> 
>> May I propose the attached patch to fix?
> 
> For some reason, the original patch contained a typo (don't ask. Stupid
> IDEs). Here's the corrected one.
> 
> /Roman
>  
> 


From roman.kennke at aicas.com  Fri Oct 12 01:35:29 2007
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 12 Oct 2007 10:35:29 +0200
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <470F2EA8.5030606@sun.com>
References: <470D3AC0.5090006@sun.com> <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury> <1192129463.2826.25.camel@mercury>
	<470F2EA8.5030606@sun.com>
Message-ID: <1192178129.13489.25.camel@mercury>

Hi Christopher,

> The bug I filed against this issue is 6615656. It has not reached our 
> external bug interface yet, but should do so in the next few days. When 
> it does it will be reachable at:
>    http://bugs.sun.com/view_bug.do?bug_id=6615656

Great, thanks.

> On another note, thanks you for the contribution. I have not yet 
> reviewed it, but I am sure it will prove to be very useful.
> 
> As I am sure you are aware Sun requires all contributers to complete a
> Contributor Agreement before any contributions can be accepted. It is 
> quite straight forward and should not take any time at all to complete. 
> You can find a link to the agreement as well as an FAQ and details of 
> how to submit it at the following location:
>    https://sca.dev.java.net/CA_signatories.htm

I already signed the agreement. You should find my name in the proper
list (can't find the URL right now, but I'm sure you know it).

/Roman
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman.kennke at aicas.com  Fri Oct 12 01:40:05 2007
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 12 Oct 2007 10:40:05 +0200
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <1192178129.13489.25.camel@mercury>
References: <470D3AC0.5090006@sun.com> <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury> <1192129463.2826.25.camel@mercury>
	<470F2EA8.5030606@sun.com>  <1192178129.13489.25.camel@mercury>
Message-ID: <1192178405.13489.28.camel@mercury>

Hi,

> >    https://sca.dev.java.net/CA_signatories.htm
> 
> I already signed the agreement. You should find my name in the proper
> list (can't find the URL right now, but I'm sure you know it).

Duh. I should actually follow the link you posted :-) My assignment is
under aicas GmbH (the company I work for), my java.net login name is
rabbit78.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Christopher.Hegarty at Sun.COM  Fri Oct 12 03:13:35 2007
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 12 Oct 2007 11:13:35 +0100
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <1192178405.13489.28.camel@mercury>
References: <470D3AC0.5090006@sun.com> <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury> <1192129463.2826.25.camel@mercury>
	<470F2EA8.5030606@sun.com> <1192178129.13489.25.camel@mercury>
	<1192178405.13489.28.camel@mercury>
Message-ID: <470F48CF.9090104@sun.com>

Yes, I see that you are already signed up.

I will proceed to review your fix and will be in contact shortly.

Regards,
-Chris.


From Christopher.Hegarty at Sun.COM  Fri Oct 12 03:56:39 2007
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 12 Oct 2007 11:56:39 +0100
Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?]
In-Reply-To: <1192129463.2826.25.camel@mercury>
References: <470D3AC0.5090006@sun.com> <470D45E3.4080300@sun.com>
	<1192125360.2826.10.camel@mercury> <1192129463.2826.25.camel@mercury>
Message-ID: <470F52E7.1010400@sun.com>

Hi Roman,

I have reviewed your proposed changes and they look fine. I agree that 
both java.net.NetworkInterface.getSubnet0 and
java.net.NetworkInterface.getBroadcast0 are unimplemented and should 
also be removed.

We should be able to remove these NetworkInterface methods under CR 
6615656 also.

I will target these changes to JDK7 b24 or b25, and will update the 
alias when I know the exact build number that they get integrated into.

Thank you for this contribution.

Regards,
-Chris.

Roman Kennke wrote:
> Hi again,
> 
>> May I propose the attached patch to fix?
> 
> For some reason, the original patch contained a typo (don't ask. Stupid
> IDEs). Here's the corrected one.
> 
> /Roman
>  
> 


From Christopher.Hegarty at Sun.COM  Fri Oct 12 05:04:14 2007
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 12 Oct 2007 13:04:14 +0100
Subject: [Fwd: Strange problem w/ RMI HTTP to CGI socket factory]
Message-ID: <470F62BE.5040705@sun.com>

Forwarding this mail to the core libs mailing list as they are most 
probably in a better position to answer it as they own the sun.rmi package.

-Chris.

-------- Original Message --------
Subject: Strange problem w/ RMI HTTP to CGI socket factory
Date: Thu, 11 Oct 2007 15:57:48 -0400
From: Sarel Botha <sarel at botha.us>
To: net-dev at openjdk.java.net

Hi All,

This problem seems strange to me and I don't know where to look to
resolve it.

The RMIHttpToCGISocketFactory class is working well for me. I call
RMISocketFactory.setSocketFactory(new RMIHttpToCGISocketFactory ()),
then Naming.lookup() and all is well. However, I need to customize this
class a little, so I got a copy of the source code for the package
sun.rmi.transport.proxy, then renamed the package for these classes to
sun.rmi.transport.proxy2 (also tried openjdk.sun.rmi.transport.proxy).

If I try to use the same class in this package I get this error when it
tries to establish the RMI connection:
java.rmi.ConnectIOException: error during JRMP connection establishment;
nested exception is:
        java.io.IOException: attempt to write on HttpSendSocket after
request has been sent
        at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286)

What's happening is that the underlying RMI code is calling
HttpSendOutputStream.write() and passing only 7 bytes. This is
immediately sent to the server which responds with only about 18 bytes.
Then, it tries to call write() again, which should never happen, so it
throws the exception you see above.

When it works (using the socket factory that ships with JRE6) it first
sends 58 bytes and the server responds with 217 bytes. You can also see
the name of the RMI service in the request and the server response
contains the name of the stub and the IP where the service is running.

It seems like the underlying implementation is treating this socket
factory totally differently from the one it ships with.

Must the code be compiled with different switches maybe? Must the socket
factory be registered somewhere? Any pointers would be appreciated.

Thanks,
Sarel


From Paul.Sandoz at Sun.COM  Fri Oct 12 06:16:44 2007
From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Fri, 12 Oct 2007 15:16:44 +0200
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <470EAEED.7000300@kennardconsulting.com>
References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com>
Message-ID: <470F73BC.4080300@Sun.Com>

Hi Richard, Michael,

Some clarifications on UriBuilder, URI templates and URI processing in 
JSR-311.

UriBuilder is primarily concerned about making easy to safely and 
efficiently build URIs. It was designed to be general in nature rather 
than scoped to a certain way in JSR-311. If it is at all specific it is 
focused on the use-cases for building and using URIs for RESTful Web 
applications. For example, given an instance of a java.net.URI how can 
one easily and safely append one or more path segments to the path 
component of that instance, or add query parameters and values to the 
query component of that instance, to create a new URI?

A UriBuilder can be created from an existing java.net.URI instance and 
then the URI components can be replaced and/or augmented (but not 
retrieved). URI templates are just one aspect of building URIs and a 
UriBuilder can be used effectively without leveraging templates (many of 
the examples provided in the Jersey, the RI, distribution do just that).

URI templates are specified in an internet draft [1], i don't know 
when/if it will become an RFC. I would not go as far to say they are "ad 
hoc", which my understanding implies a particular case, as URI templates 
are fairly general and useful so i would not discount them too early in 
the discussion process.

JSR-311 also provides access to the query parameters, path segments, and 
matrix parameters of path segments present in a URI [2].

I understood the CCC request to consider alignment as something larger 
in scope to improve both URI building and URI parsing/building of URI 
components.

JSR-311 will have to provide it's own URI-based classes but it would be 
good if we could align and improve the design in JSR-311 and JDK7.

Paul.

[1] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-01.txt
[2] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html

Richard Kennard wrote:
> Michael (Paul? Marc?),
> 
> Looking at the JSR311 URIBuilder, and with respect to Mark (Reinhold)'s 
> concerns, I actually don't think there is much of an overlap between 
> them. Specifically:
> 
> 1) javax.ws.rs.core.UriBuilder seems primarily concerned with building 
> URIs by leveraging UriTemplates
> 2) java.net.UrlEncodedQueryString seems primarily concerned with 
> modelling a query string
> 
> While 1) is useful for building URIs in a JSR311-specific way, 2) is 
> useful for parsing and retrieving and modifying query parameters (eg. 
> not solely a builder)
> 
> So while an implementation of JSR311 may want to use 
> java.net.UrlEncodedQueryString internally, I don't see how the two 
> classes could effectively merge, because UriBuilder isn't concerned with 
> parsing and retrieving and modifying, and UrlEncodedQueryString isn't 
> concerned with UriTemplates.
> 
> Regards,
> 
> Richard.
> 
> Michael McMahon wrote:
>> We have been asked by the CCC to go back and reconsider the design of 
>> the proposed
>> UrlEncodedQueryString class/API and to consider aligning it with the 
>> URIBuilder class
>> that has been proposed in JSR311. Also, the particular concern 
>> expressed by the CCC
>> is that we possibly restricted the scope of the class too much.
>>
>> What I think we would like to achieve (for Java SE) is a general 
>> purpose URI builder that is not
>> specifically tied to any particular type of web application.
>>
>> When Richard initially proposed the UrlEncodedQueryString, it was more 
>> like a URIBuilder
>> but our concern (which I think is still valid) is that a Java SE class 
>> for constructing URIs
>> must be solely based on defined standards (the URI rfcs), rather than 
>> on ad-hoc (albeit commonly used)
>> conventions in the world of web applications. Specifically, I don't 
>> think we can impose
>> any additional structure on URIs that is not explicitly specified in 
>> the relevant URIs.
>> But if other people have a different view on this, I'm interested to 
>> discuss it.
>>
>> A reference for the JSR311 class is at
>> https://jsr311.dev.java.net/nonav/javadoc/index.html
>>
>> and Paul Sandoz's blog entry talking about it is at
>> http://blogs.sun.com/sandoz/entry/building_uris
>>
>> The javadoc for the proposed UrlEncodedQueryString is attached in a 
>> zip file
>>
>> Thanks,
>> Michael.
> 
> 

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109


From Paul.Sandoz at Sun.COM  Fri Oct 12 09:25:39 2007
From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Fri, 12 Oct 2007 18:25:39 +0200
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <470F73BC.4080300@Sun.Com>
References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com>
	<470F73BC.4080300@Sun.Com>
Message-ID: <470FA003.1020406@Sun.Com>

Paul Sandoz wrote:
> Hi Richard, Michael,
> 
> Some clarifications on UriBuilder, URI templates and URI processing in 
> JSR-311.
> 
> UriBuilder is primarily concerned about making easy to safely and 
> efficiently build URIs. It was designed to be general in nature rather 
> than scoped to a certain way in JSR-311.

What i said above is slightly misleading of me, i should have said it 
was *mostly* designed to be general in nature as there are 4 methods 
associated with accessing URI templates of a class or method, but it is 
simple to generalize by removing such methods.

Paul.

> If it is at all specific it is 
> focused on the use-cases for building and using URIs for RESTful Web 
> applications. For example, given an instance of a java.net.URI how can 
> one easily and safely append one or more path segments to the path 
> component of that instance, or add query parameters and values to the 
> query component of that instance, to create a new URI?
> 
> A UriBuilder can be created from an existing java.net.URI instance and 
> then the URI components can be replaced and/or augmented (but not 
> retrieved). URI templates are just one aspect of building URIs and a 
> UriBuilder can be used effectively without leveraging templates (many of 
> the examples provided in the Jersey, the RI, distribution do just that).
> 
> URI templates are specified in an internet draft [1], i don't know 
> when/if it will become an RFC. I would not go as far to say they are "ad 
> hoc", which my understanding implies a particular case, as URI templates 
> are fairly general and useful so i would not discount them too early in 
> the discussion process.
> 
> JSR-311 also provides access to the query parameters, path segments, and 
> matrix parameters of path segments present in a URI [2].
> 
> I understood the CCC request to consider alignment as something larger 
> in scope to improve both URI building and URI parsing/building of URI 
> components.
> 
> JSR-311 will have to provide it's own URI-based classes but it would be 
> good if we could align and improve the design in JSR-311 and JDK7.
> 
> Paul.
> 
> [1] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-01.txt
> [2] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html
> 
> Richard Kennard wrote:
>> Michael (Paul? Marc?),
>>
>> Looking at the JSR311 URIBuilder, and with respect to Mark 
>> (Reinhold)'s concerns, I actually don't think there is much of an 
>> overlap between them. Specifically:
>>
>> 1) javax.ws.rs.core.UriBuilder seems primarily concerned with building 
>> URIs by leveraging UriTemplates
>> 2) java.net.UrlEncodedQueryString seems primarily concerned with 
>> modelling a query string
>>
>> While 1) is useful for building URIs in a JSR311-specific way, 2) is 
>> useful for parsing and retrieving and modifying query parameters (eg. 
>> not solely a builder)
>>
>> So while an implementation of JSR311 may want to use 
>> java.net.UrlEncodedQueryString internally, I don't see how the two 
>> classes could effectively merge, because UriBuilder isn't concerned 
>> with parsing and retrieving and modifying, and UrlEncodedQueryString 
>> isn't concerned with UriTemplates.
>>
>> Regards,
>>
>> Richard.
>>
>> Michael McMahon wrote:
>>> We have been asked by the CCC to go back and reconsider the design of 
>>> the proposed
>>> UrlEncodedQueryString class/API and to consider aligning it with the 
>>> URIBuilder class
>>> that has been proposed in JSR311. Also, the particular concern 
>>> expressed by the CCC
>>> is that we possibly restricted the scope of the class too much.
>>>
>>> What I think we would like to achieve (for Java SE) is a general 
>>> purpose URI builder that is not
>>> specifically tied to any particular type of web application.
>>>
>>> When Richard initially proposed the UrlEncodedQueryString, it was 
>>> more like a URIBuilder
>>> but our concern (which I think is still valid) is that a Java SE 
>>> class for constructing URIs
>>> must be solely based on defined standards (the URI rfcs), rather than 
>>> on ad-hoc (albeit commonly used)
>>> conventions in the world of web applications. Specifically, I don't 
>>> think we can impose
>>> any additional structure on URIs that is not explicitly specified in 
>>> the relevant URIs.
>>> But if other people have a different view on this, I'm interested to 
>>> discuss it.
>>>
>>> A reference for the JSR311 class is at
>>> https://jsr311.dev.java.net/nonav/javadoc/index.html
>>>
>>> and Paul Sandoz's blog entry talking about it is at
>>> http://blogs.sun.com/sandoz/entry/building_uris
>>>
>>> The javadoc for the proposed UrlEncodedQueryString is attached in a 
>>> zip file
>>>
>>> Thanks,
>>> Michael.
>>
>>
> 

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109


From richard at kennardconsulting.com  Fri Oct 12 15:31:56 2007
From: richard at kennardconsulting.com (Richard Kennard)
Date: Sat, 13 Oct 2007 08:31:56 +1000
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <470FA003.1020406@Sun.Com>
References: <470E083F.8000205@sun.com>
	<470EAEED.7000300@kennardconsulting.com>	<470F73BC.4080300@Sun.Com>
	<470FA003.1020406@Sun.Com>
Message-ID: <470FF5DC.1030208@kennardconsulting.com>

Paul,

 > [UriBuilder has] 4 methods associated with accessing URI templates of 
a class or method, but it is simple to generalize by removing such methods

This seems a good starting point. If I may propose a logical progression:

1. We split JSR311's UriBuilder into a JSR311-specific version and a 
generalized java.net version

2. We add further generalized methods into the java.net version to cover 
the other URI segments (scheme, host, port, authority, user-info)

3. We would now have a class that looks not unlike what I was proposing 
last year. The java.net team's objection to this class (which I agree is 
valid) was that some methods (queryParam, matrixParam) are not strictly 
part of the RFC 2396 URI spec. So we may split it again, into a 'strict 
URI' part and a 'www-form-urlencoded query string' part (which I think 
is essentially what queryParam and matrixParam are implying)

4. We agree that parsing and retrieving is also a useful feature and 
include that (the class can still be called 'builder' - StringBuilder 
has methods for retrieving, for example)

I think how we do the split in 3) is the most important decision. The 
java.net team and I tried two ways - a generalized superclass and a 
specialized subclass, and a standalone class - and preferred the latter, 
hence where we are with UrlEncodedQueryString today.

What do you think?

Regards,

Richard.

>  
>
> Paul.
>
>> If it is at all specific it is focused on the use-cases for building 
>> and using URIs for RESTful Web applications. For example, given an 
>> instance of a java.net.URI how can one easily and safely append one 
>> or more path segments to the path component of that instance, or add 
>> query parameters and values to the query component of that instance, 
>> to create a new URI?
>>
>> A UriBuilder can be created from an existing java.net.URI instance 
>> and then the URI components can be replaced and/or augmented (but not 
>> retrieved). URI templates are just one aspect of building URIs and a 
>> UriBuilder can be used effectively without leveraging templates (many 
>> of the examples provided in the Jersey, the RI, distribution do just 
>> that).
>>
>> URI templates are specified in an internet draft [1], i don't know 
>> when/if it will become an RFC. I would not go as far to say they are 
>> "ad hoc", which my understanding implies a particular case, as URI 
>> templates are fairly general and useful so i would not discount them 
>> too early in the discussion process.
>>
>> JSR-311 also provides access to the query parameters, path segments, 
>> and matrix parameters of path segments present in a URI [2].
>>
>> I understood the CCC request to consider alignment as something 
>> larger in scope to improve both URI building and URI parsing/building 
>> of URI components.
>>
>> JSR-311 will have to provide it's own URI-based classes but it would 
>> be good if we could align and improve the design in JSR-311 and JDK7.
>>
>> Paul.
>>
>> [1] 
>> http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-01.txt
>> [2] 
>> https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html
>>
>> Richard Kennard wrote:
>>> Michael (Paul? Marc?),
>>>
>>> Looking at the JSR311 URIBuilder, and with respect to Mark 
>>> (Reinhold)'s concerns, I actually don't think there is much of an 
>>> overlap between them. Specifically:
>>>
>>> 1) javax.ws.rs.core.UriBuilder seems primarily concerned with 
>>> building URIs by leveraging UriTemplates
>>> 2) java.net.UrlEncodedQueryString seems primarily concerned with 
>>> modelling a query string
>>>
>>> While 1) is useful for building URIs in a JSR311-specific way, 2) is 
>>> useful for parsing and retrieving and modifying query parameters 
>>> (eg. not solely a builder)
>>>
>>> So while an implementation of JSR311 may want to use 
>>> java.net.UrlEncodedQueryString internally, I don't see how the two 
>>> classes could effectively merge, because UriBuilder isn't concerned 
>>> with parsing and retrieving and modifying, and UrlEncodedQueryString 
>>> isn't concerned with UriTemplates.
>>>
>>> Regards,
>>>
>>> Richard.
>>>
>>> Michael McMahon wrote:
>>>> We have been asked by the CCC to go back and reconsider the design 
>>>> of the proposed
>>>> UrlEncodedQueryString class/API and to consider aligning it with 
>>>> the URIBuilder class
>>>> that has been proposed in JSR311. Also, the particular concern 
>>>> expressed by the CCC
>>>> is that we possibly restricted the scope of the class too much.
>>>>
>>>> What I think we would like to achieve (for Java SE) is a general 
>>>> purpose URI builder that is not
>>>> specifically tied to any particular type of web application.
>>>>
>>>> When Richard initially proposed the UrlEncodedQueryString, it was 
>>>> more like a URIBuilder
>>>> but our concern (which I think is still valid) is that a Java SE 
>>>> class for constructing URIs
>>>> must be solely based on defined standards (the URI rfcs), rather 
>>>> than on ad-hoc (albeit commonly used)
>>>> conventions in the world of web applications. Specifically, I don't 
>>>> think we can impose
>>>> any additional structure on URIs that is not explicitly specified 
>>>> in the relevant URIs.
>>>> But if other people have a different view on this, I'm interested 
>>>> to discuss it.
>>>>
>>>> A reference for the JSR311 class is at
>>>> https://jsr311.dev.java.net/nonav/javadoc/index.html
>>>>
>>>> and Paul Sandoz's blog entry talking about it is at
>>>> http://blogs.sun.com/sandoz/entry/building_uris
>>>>
>>>> The javadoc for the proposed UrlEncodedQueryString is attached in a 
>>>> zip file
>>>>
>>>> Thanks,
>>>> Michael.
>>>
>>>
>>
>


-- 
Richard Kennard | Principal | Kennard Consulting
0402 629 952
http://www.kennardconsulting.com



From Marc.Hadley at Sun.COM  Fri Oct 12 17:25:55 2007
From: Marc.Hadley at Sun.COM (Marc Hadley)
Date: Fri, 12 Oct 2007 20:25:55 -0400
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <470FF5DC.1030208@kennardconsulting.com>
References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com>
	<470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com>
	<470FF5DC.1030208@kennardconsulting.com>
Message-ID: <DCA698A2-E911-4EE8-9DF4-DC7E46EC895F@Sun.COM>

On Oct 12, 2007, at 6:31 PM, Richard Kennard wrote:
>
> > [UriBuilder has] 4 methods associated with accessing URI  
> templates of a class or method, but it is simple to generalize by  
> removing such methods
>
> This seems a good starting point. If I may propose a logical  
> progression:
>
> 1. We split JSR311's UriBuilder into a JSR311-specific version and  
> a generalized java.net version
>
> 2. We add further generalized methods into the java.net version to  
> cover the other URI segments (scheme, host, port, authority, user- 
> info)
>
The JSR 311 UriBuilder has methods for scheme, host, port and  
userInfo. We did have authority too but removed it since its a  
composite of some of the others.

> 3. We would now have a class that looks not unlike what I was  
> proposing last year. The java.net team's objection to this class  
> (which I agree is valid) was that some methods (queryParam,  
> matrixParam) are not strictly part of the RFC 2396 URI spec. So we  
> may split it again, into a 'strict URI' part and a 'www-form- 
> urlencoded query string' part (which I think is essentially what  
> queryParam and matrixParam are implying)
>
> 4. We agree that parsing and retrieving is also a useful feature  
> and include that (the class can still be called 'builder' -  
> StringBuilder has methods for retrieving, for example)
>
> I think how we do the split in 3) is the most important decision.  
> The java.net team and I tried two ways - a generalized superclass  
> and a specialized subclass, and a standalone class - and preferred  
> the latter, hence where we are with UrlEncodedQueryString today.
>
> What do you think?
>
I think it would make sense for the JSR 311 class to extend a  
generalized java.net class since we'd want to add support for URI  
templates. That support is pervasive so its not just a case of adding  
new methods, we'd want to override existing ones to allow URI  
templates to be used within their values.

Regards,
Marc.

>>
>>> If it is at all specific it is focused on the use-cases for  
>>> building and using URIs for RESTful Web applications. For  
>>> example, given an instance of a java.net.URI how can one easily  
>>> and safely append one or more path segments to the path component  
>>> of that instance, or add query parameters and values to the query  
>>> component of that instance, to create a new URI?
>>>
>>> A UriBuilder can be created from an existing java.net.URI  
>>> instance and then the URI components can be replaced and/or  
>>> augmented (but not retrieved). URI templates are just one aspect  
>>> of building URIs and a UriBuilder can be used effectively without  
>>> leveraging templates (many of the examples provided in the  
>>> Jersey, the RI, distribution do just that).
>>>
>>> URI templates are specified in an internet draft [1], i don't  
>>> know when/if it will become an RFC. I would not go as far to say  
>>> they are "ad hoc", which my understanding implies a particular  
>>> case, as URI templates are fairly general and useful so i would  
>>> not discount them too early in the discussion process.
>>>
>>> JSR-311 also provides access to the query parameters, path  
>>> segments, and matrix parameters of path segments present in a URI  
>>> [2].
>>>
>>> I understood the CCC request to consider alignment as something  
>>> larger in scope to improve both URI building and URI parsing/ 
>>> building of URI components.
>>>
>>> JSR-311 will have to provide it's own URI-based classes but it  
>>> would be good if we could align and improve the design in JSR-311  
>>> and JDK7.
>>>
>>> Paul.
>>>
>>> [1] http://www.ietf.org/internet-drafts/draft-gregorio- 
>>> uritemplate-01.txt
>>> [2] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/ 
>>> UriInfo.html
>>>
>>> Richard Kennard wrote:
>>>> Michael (Paul? Marc?),
>>>>
>>>> Looking at the JSR311 URIBuilder, and with respect to Mark  
>>>> (Reinhold)'s concerns, I actually don't think there is much of  
>>>> an overlap between them. Specifically:
>>>>
>>>> 1) javax.ws.rs.core.UriBuilder seems primarily concerned with  
>>>> building URIs by leveraging UriTemplates
>>>> 2) java.net.UrlEncodedQueryString seems primarily concerned with  
>>>> modelling a query string
>>>>
>>>> While 1) is useful for building URIs in a JSR311-specific way,  
>>>> 2) is useful for parsing and retrieving and modifying query  
>>>> parameters (eg. not solely a builder)
>>>>
>>>> So while an implementation of JSR311 may want to use  
>>>> java.net.UrlEncodedQueryString internally, I don't see how the  
>>>> two classes could effectively merge, because UriBuilder isn't  
>>>> concerned with parsing and retrieving and modifying, and  
>>>> UrlEncodedQueryString isn't concerned with UriTemplates.
>>>>
>>>> Regards,
>>>>
>>>> Richard.
>>>>
>>>> Michael McMahon wrote:
>>>>> We have been asked by the CCC to go back and reconsider the  
>>>>> design of the proposed
>>>>> UrlEncodedQueryString class/API and to consider aligning it  
>>>>> with the URIBuilder class
>>>>> that has been proposed in JSR311. Also, the particular concern  
>>>>> expressed by the CCC
>>>>> is that we possibly restricted the scope of the class too much.
>>>>>
>>>>> What I think we would like to achieve (for Java SE) is a  
>>>>> general purpose URI builder that is not
>>>>> specifically tied to any particular type of web application.
>>>>>
>>>>> When Richard initially proposed the UrlEncodedQueryString, it  
>>>>> was more like a URIBuilder
>>>>> but our concern (which I think is still valid) is that a Java  
>>>>> SE class for constructing URIs
>>>>> must be solely based on defined standards (the URI rfcs),  
>>>>> rather than on ad-hoc (albeit commonly used)
>>>>> conventions in the world of web applications. Specifically, I  
>>>>> don't think we can impose
>>>>> any additional structure on URIs that is not explicitly  
>>>>> specified in the relevant URIs.
>>>>> But if other people have a different view on this, I'm  
>>>>> interested to discuss it.
>>>>>
>>>>> A reference for the JSR311 class is at
>>>>> https://jsr311.dev.java.net/nonav/javadoc/index.html
>>>>>
>>>>> and Paul Sandoz's blog entry talking about it is at
>>>>> http://blogs.sun.com/sandoz/entry/building_uris
>>>>>
>>>>> The javadoc for the proposed UrlEncodedQueryString is attached  
>>>>> in a zip file
>>>>>
>>>>> Thanks,
>>>>> Michael.
>>>>
>>>>
>>>
>>
>
>
> -- 
> Richard Kennard | Principal | Kennard Consulting
> 0402 629 952
> http://www.kennardconsulting.com
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.




From richard at kennardconsulting.com  Fri Oct 12 23:19:47 2007
From: richard at kennardconsulting.com (Richard Kennard)
Date: Sat, 13 Oct 2007 16:19:47 +1000
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <DCA698A2-E911-4EE8-9DF4-DC7E46EC895F@Sun.COM>
References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com>
	<470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com>
	<470FF5DC.1030208@kennardconsulting.com>
	<DCA698A2-E911-4EE8-9DF4-DC7E46EC895F@Sun.COM>
Message-ID: <47106383.5010900@kennardconsulting.com>

Marc,

Thanks for your reply.

 > The JSR 311 UriBuilder has methods for scheme, host, port and 
userInfo. We did have authority too but removed it since its a composite 
of some of the others.

Right, sorry - I missed those when I was looking at the JavaDoc.

 > I think it would make sense for the JSR 311 class to extend a 
generalized java.net class since we'd want to add support for URI templates.

Agreed.

However we need to decide what to do about query parameters and matrix 
parameters. I imagine you would want them in the base class, but the 
java.net team are going to suggest they don't belong in a 'pure' 
UriBuilder and will want them split out somehow?

Regards,

Richard.


From Michael.McMahon at Sun.COM  Tue Oct 16 05:46:46 2007
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 16 Oct 2007 13:46:46 +0100
Subject: UrlEncodedQueryString CCC request
In-Reply-To: <DCA698A2-E911-4EE8-9DF4-DC7E46EC895F@Sun.COM>
References: <470E083F.8000205@sun.com> <470EAEED.7000300@kennardconsulting.com>
	<470F73BC.4080300@Sun.Com> <470FA003.1020406@Sun.Com>
	<470FF5DC.1030208@kennardconsulting.com>
	<DCA698A2-E911-4EE8-9DF4-DC7E46EC895F@Sun.COM>
Message-ID: <4714B2B6.8010800@sun.com>

I agree with most of the suggestions below. The main things
we want are:

1) alignment, ie. the JSR311 class extends the java.net class
    although I would imagine that if JSR311 is finalised before jdk7
    then it will not initially extend it. So, it should at least be aligned
    sufficiently so that it could extend the java.net class in the future

2) then we combine the building capabilities of UriBuilder (probably use 
that name also)
    with the retrieval/query manipulation capabilities of 
UrlEncodedQueryString.
    I think the method names from UrlEncodedQueryString will have to 
change though
   eg addParameter() would need to be addQueryParameter() etc.

Some questions.

1) I'm not familiar with the notion of  "matrix" parameters. Google seems to
    only reveal one old w3c article about them. Are they more widely 
used than this?
    If the concept is more specific to JSR311, then I think I'd prefer 
to leave them
    out of the java.net. class

2) Initially I was sceptical about URI templates, and I do think that the
   general class probably doesn't need any of the methods related to
   reflection/annotation processing (of URI templates), but it does look 
like a useful feature
   and it's worth considering supporting the build() capability which 
replaces
   {} templates with specific instance values from the Map passed in.
   The risk of course is that the specification for URI templates could 
change
   before it is standardised by the IETF.

Thanks
Michael.

Marc Hadley wrote:
> On Oct 12, 2007, at 6:31 PM, Richard Kennard wrote:
>>
>> > [UriBuilder has] 4 methods associated with accessing URI templates 
>> of a class or method, but it is simple to generalize by removing such 
>> methods
>>
>> This seems a good starting point. If I may propose a logical 
>> progression:
>>
>> 1. We split JSR311's UriBuilder into a JSR311-specific version and a 
>> generalized java.net version
>>
>> 2. We add further generalized methods into the java.net version to 
>> cover the other URI segments (scheme, host, port, authority, user-info)
>>
> The JSR 311 UriBuilder has methods for scheme, host, port and 
> userInfo. We did have authority too but removed it since its a 
> composite of some of the others.
>
>> 3. We would now have a class that looks not unlike what I was 
>> proposing last year. The java.net team's objection to this class 
>> (which I agree is valid) was that some methods (queryParam, 
>> matrixParam) are not strictly part of the RFC 2396 URI spec. So we 
>> may split it again, into a 'strict URI' part and a 
>> 'www-form-urlencoded query string' part (which I think is essentially 
>> what queryParam and matrixParam are implying)
>>
>> 4. We agree that parsing and retrieving is also a useful feature and 
>> include that (the class can still be called 'builder' - StringBuilder 
>> has methods for retrieving, for example)
>>
>> I think how we do the split in 3) is the most important decision. The 
>> java.net team and I tried two ways - a generalized superclass and a 
>> specialized subclass, and a standalone class - and preferred the 
>> latter, hence where we are with UrlEncodedQueryString today.
>>
>> What do you think?
>>
> I think it would make sense for the JSR 311 class to extend a 
> generalized java.net class since we'd want to add support for URI 
> templates. That support is pervasive so its not just a case of adding 
> new methods, we'd want to override existing ones to allow URI 
> templates to be used within their values.
>
> Regards,
> Marc.
>



From peter.jones at Sun.COM  Fri Oct 12 10:21:35 2007
From: peter.jones at Sun.COM (Peter Jones)
Date: Fri, 12 Oct 2007 13:21:35 -0400
Subject: [Fwd: Strange problem w/ RMI HTTP to CGI socket factory]
In-Reply-To: <470F62BE.5040705@sun.com>
References: <470F62BE.5040705@sun.com>
Message-ID: <20071012172135.GA14796@east>

On Fri, Oct 12, 2007 at 01:04:14PM +0100, Christopher Hegarty - Sun Microsystems Ireland wrote:
> Forwarding this mail to the core libs mailing list as they are most 
> probably in a better position to answer it as they own the sun.rmi package.
>
> -Chris.

Thanks for the forward, Chris:

> -------- Original Message --------
> Subject: Strange problem w/ RMI HTTP to CGI socket factory
> Date: Thu, 11 Oct 2007 15:57:48 -0400
> From: Sarel Botha <sarel at botha.us>
> To: net-dev at openjdk.java.net
>
> Hi All,
>
> This problem seems strange to me and I don't know where to look to
> resolve it.
>
> The RMIHttpToCGISocketFactory class is working well for me. I call
> RMISocketFactory.setSocketFactory(new RMIHttpToCGISocketFactory ()),
> then Naming.lookup() and all is well. However, I need to customize this
> class a little, so I got a copy of the source code for the package
> sun.rmi.transport.proxy, then renamed the package for these classes to
> sun.rmi.transport.proxy2 (also tried openjdk.sun.rmi.transport.proxy).
>
> If I try to use the same class in this package I get this error when it
> tries to establish the RMI connection:
> java.rmi.ConnectIOException: error during JRMP connection establishment;
> nested exception is:
>        java.io.IOException: attempt to write on HttpSendSocket after
> request has been sent
>        at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286)
>
> What's happening is that the underlying RMI code is calling
> HttpSendOutputStream.write() and passing only 7 bytes. This is
> immediately sent to the server which responds with only about 18 bytes.
> Then, it tries to call write() again, which should never happen, so it
> throws the exception you see above.
>
> When it works (using the socket factory that ships with JRE6) it first
> sends 58 bytes and the server responds with 217 bytes. You can also see
> the name of the RMI service in the request and the server response
> contains the name of the stub and the IP where the service is running.
>
> It seems like the underlying implementation is treating this socket
> factory totally differently from the one it ships with.
>
> Must the code be compiled with different switches maybe? Must the socket
> factory be registered somewhere? Any pointers would be appreciated.

First I should caution that the sun.rmi.transport.proxy package is a
relatively delicate old corner of the implementation (it has barely
been touched in 11 years)-- extending it is both somewhat risky and
not supported by public Java SE APIs (for better or for worse).

I suspect what your problem is:

The implementation of the HTTP tunnelling provided by this package is
presented (to the higher RMI/JRMP protocol implementation code) using
java.net.Socket as an abstraction for an HTTP request/response pair,
which is really not a very fitting abstraction, because with a Socket
one can normally assume a full-duplex connection.

The JRMP implementation code must understand what kind of "Socket" it
is using in order to know whether to use JRMP's StreamProtocol (for a
regular TCP connection or equivalent) or the SingleOpProtocol (for an
HTTP-tunnelled remote invocation).[1]  The implementation actually
makes this distinction based on whether the Socket is an instance of
the sun.rmi.transport.proxy.RMISocketInfo interface, and if it is,
what an invocation of its isReusable() method returns-- if it is an
instance of that interface and if isReusable returns false, HTTP
tunnelling is assumed and the SingleOpProtocol is used; otherwise, a
normal Socket is assumed and the StreamProtocol is used.

So, if you completely cloned the sun.rmi.transport.proxy package, then
your HttpSendSocket class presumably implements an incompatible
RMISocketInfo interface, and thus it will not be recognized as only
supporting request/response usage.  If you make the class implement
the original sun.rmi.transport.proxy.RMISocketInfo interface, that
should fix this problem, but all of the caveats of depending on sun.*
APIs would apply.[2]

Some previous discussion of a similar problem is here:
    http://archives.java.sun.com/cgi-bin/wa?A2=ind0104&L=rmi-users&P=35726

-- Peter

[1] These modes are described here:
http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol3.html
[2] http://java.sun.com/products/jdk/faq/faq-sun-packages.html


From rabelenda at gmail.com  Tue Oct 30 06:42:14 2007
From: rabelenda at gmail.com (Roger Abelenda)
Date: Tue, 30 Oct 2007 11:42:14 -0200
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
Message-ID: <975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>

Hi I'm implementing an DatagramSocket and a
datagramPacket and I want to subsitute the ones of the jvm with this
ones. If you know: where may I put my code and what shall I do to make
it compile when I compile the jvm?, and , what changes Ii need to do to
plug it into the original code to make the jvm call my classes when
somebody calls the original ones?. I thought to change the
classloader.c  and the resolve.c. Any other options? thanks.


From Alan.Bateman at Sun.COM  Tue Oct 30 11:05:42 2007
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 30 Oct 2007 18:05:42 +0000
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
	<975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
Message-ID: <47277276.8020602@sun.com>

Roger Abelenda wrote:
> Hi I'm implementing an DatagramSocket and a
> datagramPacket and I want to subsitute the ones of the jvm with this
> ones. If you know: where may I put my code and what shall I do to make
> it compile when I compile the jvm?, and , what changes Ii need to do to
> plug it into the original code to make the jvm call my classes when
> somebody calls the original ones?. I thought to change the
> classloader.c  and the resolve.c. Any other options? thanks.
>   
As DatagramSocket and DatagramPacket are created by public constructors 
then you'll need to replace the existing classes. As a first step, for 
testing purposes, it might be easier to prepend your classes to the boot 
class path rather than replacing the classes in the build. Another 
approach is to create a DatagramSocketImpl and use the 
setDatagramSocketImplFactory method to set a factory that instantiates 
your impl rather than the default. Can you provide a few more details on 
what you are trying to do? If you are trying to fix a bug or add a 
feature then maybe it would be easier to contribute changes to the 
existing code rather than replacing them.

-Alan.


From rabelenda at gmail.com  Tue Oct 30 12:40:15 2007
From: rabelenda at gmail.com (Roger Abelenda)
Date: Tue, 30 Oct 2007 17:40:15 -0200
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <47277276.8020602@sun.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
	<975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
	<47277276.8020602@sun.com>
Message-ID: <975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com>

I'm in an academic project implementing an ipv6 stack entirely with
java in the jvm, and make the jvm by default call my ipv6 stack.
Thanks for advice, i'll try.

2007/10/30, Alan Bateman <Alan.Bateman at sun.com>:
> Roger Abelenda wrote:
> > Hi I'm implementing an DatagramSocket and a
> > datagramPacket and I want to subsitute the ones of the jvm with this
> > ones. If you know: where may I put my code and what shall I do to make
> > it compile when I compile the jvm?, and , what changes Ii need to do to
> > plug it into the original code to make the jvm call my classes when
> > somebody calls the original ones?. I thought to change the
> > classloader.c  and the resolve.c. Any other options? thanks.
> >
> As DatagramSocket and DatagramPacket are created by public constructors
> then you'll need to replace the existing classes. As a first step, for
> testing purposes, it might be easier to prepend your classes to the boot
> class path rather than replacing the classes in the build. Another
> approach is to create a DatagramSocketImpl and use the
> setDatagramSocketImplFactory method to set a factory that instantiates
> your impl rather than the default. Can you provide a few more details on
> what you are trying to do? If you are trying to fix a bug or add a
> feature then maybe it would be easier to contribute changes to the
> existing code rather than replacing them.
>
> -Alan.
>


From rabelenda at gmail.com  Wed Oct 31 10:00:06 2007
From: rabelenda at gmail.com (Roger Abelenda)
Date: Wed, 31 Oct 2007 15:00:06 -0200
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
	<975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
	<47277276.8020602@sun.com>
	<975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com>
Message-ID: <975ae7d10710311000t6cf723dbwea13006691f044bc@mail.gmail.com>

I also need to make other classes in my implementation (apart of the
Datagrams) visible by any class when i'm using the "modifyed" jvm. I'm
meaning thath those classes can be imported without setting nothing
after compiling de jvm. I want to make them part of the standard
classpath. Suggestions?

2007/10/30, Roger Abelenda <rabelenda at gmail.com>:
> I'm in an academic project implementing an ipv6 stack entirely with
> java in the jvm, and make the jvm by default call my ipv6 stack.
> Thanks for advice, i'll try.
>
> 2007/10/30, Alan Bateman <Alan.Bateman at sun.com>:
> > Roger Abelenda wrote:
> > > Hi I'm implementing an DatagramSocket and a
> > > datagramPacket and I want to subsitute the ones of the jvm with this
> > > ones. If you know: where may I put my code and what shall I do to make
> > > it compile when I compile the jvm?, and , what changes Ii need to do to
> > > plug it into the original code to make the jvm call my classes when
> > > somebody calls the original ones?. I thought to change the
> > > classloader.c  and the resolve.c. Any other options? thanks.
> > >
> > As DatagramSocket and DatagramPacket are created by public constructors
> > then you'll need to replace the existing classes. As a first step, for
> > testing purposes, it might be easier to prepend your classes to the boot
> > class path rather than replacing the classes in the build. Another
> > approach is to create a DatagramSocketImpl and use the
> > setDatagramSocketImplFactory method to set a factory that instantiates
> > your impl rather than the default. Can you provide a few more details on
> > what you are trying to do? If you are trying to fix a bug or add a
> > feature then maybe it would be easier to contribute changes to the
> > existing code rather than replacing them.
> >
> > -Alan.
> >
>


From Alan.Bateman at Sun.COM  Wed Oct 31 12:01:52 2007
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 31 Oct 2007 19:01:52 +0000
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <975ae7d10710311000t6cf723dbwea13006691f044bc@mail.gmail.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
	<975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
	<47277276.8020602@sun.com>
	<975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com>
	<975ae7d10710311000t6cf723dbwea13006691f044bc@mail.gmail.com>
Message-ID: <4728D120.3000603@sun.com>

Roger Abelenda wrote:
> I also need to make other classes in my implementation (apart of the
> Datagrams) visible by any class when i'm using the "modifyed" jvm. I'm
> meaning thath those classes can be imported without setting nothing
> after compiling de jvm. I want to make them part of the standard
> classpath. Suggestions?
>   
Any supporting/implementation classes will likely need to be on the boot 
class path. Depending on how you are making this available this means 
they'll be in rt.jar or some other JAR file on your boot class path. Is 
your interest only UDP? If not, then I assume you will also need to 
think about the Socket classes and also create your own SelectorProvider 
so that NIO channels can use your IPv6 stack.

-Alan.


From rabelenda at gmail.com  Wed Oct 31 15:59:37 2007
From: rabelenda at gmail.com (Roger Abelenda)
Date: Wed, 31 Oct 2007 19:59:37 -0300
Subject: Fwd: custom DatagramSocket and DatagramPacket
In-Reply-To: <4728D120.3000603@sun.com>
References: <975ae7d10710300639n9e108fcye238faf0c9009472@mail.gmail.com>
	<975ae7d10710300642s739acb99g6416117b6577b8a0@mail.gmail.com>
	<47277276.8020602@sun.com>
	<975ae7d10710301240v7d251dafvc2f98f403bfbfb3d@mail.gmail.com>
	<975ae7d10710311000t6cf723dbwea13006691f044bc@mail.gmail.com>
	<4728D120.3000603@sun.com>
Message-ID: <975ae7d10710311559h1ed73a9ev873c1176ace02f7c@mail.gmail.com>

Thath's right, i want in the future not only implment UDP. And how do
i modify the makefile to make it put my classes in the apropiate jar,
in which jar you think i would put the things? and which files may i
modify?.

2007/10/31, Alan Bateman <Alan.Bateman at sun.com>:
> Roger Abelenda wrote:
> > I also need to make other classes in my implementation (apart of the
> > Datagrams) visible by any class when i'm using the "modifyed" jvm. I'm
> > meaning thath those classes can be imported without setting nothing
> > after compiling de jvm. I want to make them part of the standard
> > classpath. Suggestions?
> >
> Any supporting/implementation classes will likely need to be on the boot
> class path. Depending on how you are making this available this means
> they'll be in rt.jar or some other JAR file on your boot class path. Is
> your interest only UDP? If not, then I assume you will also need to
> think about the Socket classes and also create your own SelectorProvider
> so that NIO channels can use your IPv6 stack.
>
> -Alan.
>