Re: [Fwd: PlainSocketImpl.socketGetOption1() ?]
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
Re: [Fwd: PlainSocketImpl.socketGetOption1() ?]
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
Re: [Fwd: PlainSocketImpl.socketGetOption1() ?]
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
[Fwd: Strange problem w/ RMI HTTP to CGI socket factory]
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 <[EMAIL PROTECTED]> To: net-dev@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
Re: [Fwd: PlainSocketImpl.socketGetOption1() ?]
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
Re: [Fwd: PlainSocketImpl.socketGetOption1() ?]
Yes, I see that you are already signed up. I will proceed to review your fix and will be in contact shortly. Regards, -Chris.
Re: UrlEncodedQueryString CCC request
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
Re: UrlEncodedQueryString CCC request
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
Re: UrlEncodedQueryString CCC request
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 ref
Re: UrlEncodedQueryString CCC request
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
Re: UrlEncodedQueryString CCC request
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.
