Steve,
Fair enough.
I downloaded NetBeans, cloned the OpenJDK repo, and updated my code. I tried to
submit a patch but http://openjdk.java.net/contribute says to use
https://bugs.openjdk.java.net, which says...
"this site will only be accepting and tracking patch contributions to the
OpenJ
On Sun, 2011-10-16 at 20:41 -0700, kennardconsulting wrote:
> Hi guys,
>
> So I'm just back from JavaOne 2011 and I'm all fired up about Open JDK again
> :)
>
> I thought it may be worth revisiting RFE 6306820? All the hard work for this
> RFE has already been done. There is a solid implementatio
Here is my suggestion. It probably makes sense to keep two separate
classes, even though UriBuilder can potentially
be used to create any possible URI. I think it is still useful to be
able to manipulate query parameters independent
of the URI that they are to be applied to, and I think the abi
Marc,
> The builder is strictly that, a builder, so I'm not sure if it makes
sense to add read capabilities to it
Agreed. I actually don't think these two classes (UriBuilder and
UrlEncodedQueryString) overlap much. How about I propose this as a
direction:
1. JSR-311's UriBuilder plans to
On Nov 1, 2007, at 5:45 AM, Michael McMahon wrote:
I wonder if you have an opinion on the points/questions raised below?
I'd like to get agreement on the general shape of the API before
anyone goes off and reworks the existing proposal.
Some comments interspersed below.
Michael McMahon wrot
Marc & Paul,
I wonder if you have an opinion on the points/questions raised below?
I'd like to get agreement on the general shape of the API before
anyone goes off and reworks the existing proposal.
Thanks
Michael.
Michael McMahon wrote:
I agree with most of the suggestions below. The main thi
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
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
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 J
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
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 JS
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 a
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) ja
Michael,
Thanks for everybody's input! I will only reply to those points that
need further discussion. I'll post a new version with the other changes
people brought up.
> We need to support both separator types in the same input strings.
Though I thought that
> the original separators had to
Christopher Hegarty - Sun Microsystems Ireland wrote:
Questions (Sorry, of this has come up before):
1) Why have overloaded versions of toString and parse. Why not one
method called setSeparator?
We need to support both separator types in the same input strings.
Though I thought that
the orig
--- Begin Message ---
Max (Weijun) Wang wrote:
1. How about setParameters(String name, List values) so that I
can set a multivalued parameter in one call?
I think the most likely use case, is when you dynamically add the
parameters one at a time,
but that case is certainly possible. But I'd
--- Begin Message ---
Forget question 4. I can see that Number.toString will handle this.
-Chris.
Christopher Hegarty - Sun Microsystems Ireland wrote:
Questions (Sorry, of this has come up before):
1) Why have overloaded versions of toString and parse. Why not one
method called setSeparator
--- Begin Message ---
Questions (Sorry, of this has come up before):
1) Why have overloaded versions of toString and parse. Why not one
method called setSeparator?
2) Does getParameterNames return multiple entries for multiple name
value pairs. I think not.
3) Do we really need removeParamete
--- Begin Message ---
1. How about setParameters(String name, List values) so that
I can set a multivalued parameter in one call?
2. Why undefined result when input string is not a url-encoded query
string? Why not throw an Exception?
3. public static UrlEncodedQueryString create
(Map> p
19 matches
Mail list logo
