Hi,
Marc Hadley wrote:
> On Mar 13, 2008, at 7:48 AM, Stephan Koops wrote:
>> UriInfo.getAncestorResource*()
>> • I think it is better to return the root resource class (and
>> especially the URI) as last and not as first. Did anyone think, the
>> root resource class should be at the beginning? I remember, that Marc
>> said, he has no special preferences.
> No special preference, it seems logical to list the resources in the
> order you encounter them but I could live with the reverse. Is the
> intent to make it easier to get the direct parent ?
Yes. My old use case :-).
In my last email I forget, that IMO it should be possible to use
int firstOrLastIndex = ...; // see above
URI relParentUri = uriInfo.getAnchestorResourceURIs().get(firstOrLastIndex);
uriInfo.getBaseUriBuilder().path(relParentUri); // here is .toString()
needed now
Until now it is not possible, because path(URI) is not available. You
must call relParentUri.toString(). It is easier for app developers, if
it is possible without calling .toString().
Two solutions come into my head: change the return type to List<String>
instead of List<URI> or add a method UriBuilder.path(URI) with the same
semantic as path(String). The available method UriBuilder.uri(URI)
replaces the current path instead of appending the new path.
>> • I think it is good to add in the javadoc explicit, that the
>> query is never returned.
> OK. What about matrix parameters ? I currently think they should be
> included but I'm open to arguments against.
Yes, I also think matrix parameters should be added. If it is used to
create a parent (or grand parent) URI, typically the matrix parameters
are also needed.
>> UriBuilder
>> • build(int...)? I think it is useful to add
>> UriBuilder.build(int...), because often IDs are used for the URI
>> build, and they are often Integers (but never null). I know that we
>> could add a lot of other methods here, but I think this is a common
>> use case.
> Hmmm. Rather than doing that how about changing build(String...) to
> build(Object...) and requiring that Object.toString is used to get a
> parameter value. Then we can take advantage of autoboxing to support
> primitive types.
Yes, also good. Two specialized methods are more explicit what is meant,
but your proposal is very flexible and you could combine ints, Strings
and whatever.
BTW: What about null values? Forbid or tread as ""? I think forbid.
Semanticly it is perhaps useful to remove a query or matrix parameter if
null is given for it's value, but I think the logic get very complex then.
>> • port(String)? If template variables should also be allowed for
>> the port, than we need UriBuilder.port(String). I think it should
>> only be possible to set a port (0 (or1?) until 65535 (=2**16-1) ) or
>> one template variable and nothing else. To unset the explicit port
>> null should be used. For uriBuilder.port("808{lastPortDigit}") or
>> something like this there is only a very little number of use cases
>> and will complicates the algorithm to check for validity.
> I can't see port(String) being used much - do we really need it ?
The intention comes while implementing UriBuilder.schemeSpecificPart(.).
There it is possible to give a template variable for the port. But I
think it is not a useful way to set a port template variable by
replacing the full scheme specific part. Is there another way to vary
the port with a template variable?
>> Constructors of root resource classes and providers
>> I think it is useful to define also in the spec, that only
>> constructors are checked, if they are valid [...]
> I don't understand what you mean, can you explain more ?
Sorry, I forget the word "public". Use only public constructors.
>> JSR 250 dependency
>> The common dependency to JSR 250 for resource classes is placed in
>> the javadoc of @Path. In the specification it is only available in
>> the note to Java EE container. I think it is useful to put this from
>> the @Path javadoc to the specification file, perhaps into the section
>> "Constructors" of chapter "Resources". I think it is also useful for
>> the providers.
> Agree on removing it from @Path. Some of the JSR 250 annotations only
> really make sense in an EE context so we may want to confine mention
> of those annotations to the EE section of the spec.
In @Path were only @PostConstruct and @PreDestroy defined to be
honoured. I think, some initialization is also useful on non-EE
environments. I've already implemented this both.
best regards
Stephan