Hi Stephan,
Stephan Koops wrote:
> Hello Paul,
>
> some questions are already open for me; perhaps the answers don't reach me:
>
> *extension mapping*
>
> * should the extension mapping ignore @ProduceMime, if available?
> * Perhaps it is useful to allow different mime types for some
> extensions (e.g. "application/xml" and "text/xml") and check, if
> the client only accept one of them.
>
> *_at_Path*
> Are matrix parameters allowed or not? I think it' should be not required.
>
> *UriBuilder*
> What about a method uriBuilder.parent() that removes the last path
> segment of the actual state?
>
> *EntityProvider for javax.xml.transform.Source*
> Where should the transformer get it's XSLT Source? Are I missing something?
> Otherwise the XSLT source could be defined by an defined annotation.
>
> *_at_Provider*
> For what is the annotation @Provider needed?
> The ApplicationConfig contains all Providers, so it's not needed to find
> the providers (in the classpath or whereever). Another possibility to
> identify them is to check, if the classes implement at least one of the
> interfaces.
>
See attached, i recommend you subscribe to the jsr311 users list that
way you will receive emails as they are sent (plus we don't have to keep
approving the emails you send :-) )
> /Some new questions:/
> *MessageBodyWriter / MessageBodyReader*
>
> * Must the httpHeaders in MessageBodyWriter.writeTo(...) be mutable
> or is it enough if the may they be mutable?
> * I think it is also useful to define if the httpHeaders in
> MessageBodyReader.readFrom(...) are mutable or not. I think they
> should be immutable. Perhaps it is useful to define two different
> interfaces for readable MultivaluedMaps and a sub interface which
> allows changes (see attachment). I know, it's late, but there are
> a lot of points where it is useful. I think collection interfaces
> without requiring changes are missing in java.
You raise some good points. I would like to discuss the
immutable/mutable aspects with Marc when he returns on Thursday.
> * If I remember right, it's not defined what should happens, if no
> MessageBodyWriter (and also MessageBodyReader) could be found.
> Should status 406 (Not Acceptable) respectivly 422 (Unprocessable
> Entity) returned?
>
Hmm... at the moment the RI throws an exception that results in a 500.
But i think the error codes you state make sense.
> *JAXB*
> It's nowhere defined which JAXB version is required. Is it container
> dependant, or should a required version be defined? JAXB v1 doesn't
> support annotations, if I remember right, so this isn't useful. But
> there are also JAXB v2.0 and v2.1, I think.
>
On first thought I suppose either JAXB 2.0 or 2.1 can be supported as we
don't explicitly depend on the API. But that may have implications for
portability. IIUC 2.1 should support 2.0-based JAXB classes, so it seems
sensible to say 2.1 must be supported.
> *ContextResolver*
> I found not when to use it.
> Where should the environment inject it?
Perhaps an example would help, see the StorageServer example in the
trunk of the RI and search for the class JAXBContextResolver, then look
at the com.sun.ws.rest.impl.provider.entity.AbstractJAXBElementProvider.
The injected value on AbstractJAXBElementProvider is an aggregation of
all the user-specified classes.
> What
> type of context should be returned of method
> ContextResolver.getContext(Class)?
>
You mean when no generic type is specified?
Paul.
> best regards
> Stephan
>
> Paul Sandoz schrieb:
>> Hi Sergey,
>>
>> See my attached response to Jervis (for 0.5). A stable release of the
>> RI and the API will be available on Fri March 7th and that will be
>> published to the java.net maven repo.
>>
>> Is it causing annoying problems to the CXF development process to wait
>> until March 7th or is that too long to wait?
>>
>> Stephan, Bill, is the current release process causing issues for you
>> as well?
>>
>> Paul.
>>
>> Sergey Beryozkin wrote:
>>> Hi
>>>
>>> Is it possible to publish a 0.6 version of api to one of the public
>>> Maven repositories ?
>>> 0.6 replaces @UriParam with @PathParam which affects the users' code,
>>> thus in CXF we'd like to switch to 0.6 as early as possible.
>>>
>>> Thanks, Sergey Beryozkin
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
attached mail follows:
On Feb 21, 2008, at 9:02 AM, Stephan Koops wrote:
>
> ApplicationConfig
> The ApplicationConfig is a very good idea. I have a two questions /
> proposals to the extensionMappings:
> • What should happens, if the returning method produces mimes
> (declared by @ProduceMime), that are not compatible with the
> extension mapping? Or should the runtime completely ignore
> @ProduceMime, if a mime type ist found in the extension mapping? Or
> should the runtime only search in the extension mapping map, if
> there is no @ProduceMime.
The idea is that the URI extension is an alternative to specifying the
Accept header, so the JSR 311 runtime would only ever call methods
whose ProduceMime matches the Accept/extension. Essentially:
GET /foo.xml
would be equivalent to
GET /foo
Accept: application/xml
with a suitable extension mapping configured.
>
> • If the @ProduceMime or the accepted media types should be
> respected, than I propose to return a Map<String,
> Collection<MediaType>> instead of Map<String, MediaType>. This is
> useful (e.g. for XML ["text/xml" and "application/xml"] and also for
> JavaScript files ["text/javascript" and "application/x-
> javascript"]), if the bowser acceptes only one of this MediaTypes.
> By design criteria a Set is the best, but I think it should be
> possible to order them, so a List should also be possible. So
> Collection is a flexibel solution.
Are you suggesting we'd filter the list/set returned from the mapping
config against the actual Accept header sent in the request ?
> UriBuilder
> What about a method UriBuilder.parent()? It should remove the last
> path segment. So the application developer must not think about if
> the resource class is a direct subclass of the root resource class
> or if there are other sub resource classes between them. It's
> necessary if a representation of collection element should contain
> an URI to it's collection.
>
I guess that would be useful in the case that the parent resource
isn't a root resource. We have issue 7:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=7
which I think is related to this.
> ContextResolver
> Do you inserted the ContextResolver as reaction to my email from
> 2008-02-15 (see end of this email)? I think, this is a complex
> solution. Up to now all provider classes could be singeltons; now I
> have to provide different provider instances for different
> ContextResolvers.
> If I think to complicated, let me know.
>
No, this wasn't directly related to that issue. As discussed I will
add additional parameters to the message body reader and writer
methods so you can access the generic type information.
ContextResolver is designed to allow an application to manage
serialization contexts. A concrete use case is the management of
JAXBContext, currently the JAXB provider has to manage its own
JAXBContext, ContextResolver allows the application to create the
JAXBContext that will be used for serializing or deserializing a
particular class.
Provider classes can still be singletons, an injected ContextResolver
is responsible for finding a ContextResolver that will provide a
context for a particular class by going through the list of providers
for a particular type. I still need to update the spec to describe
this in more detail.
> unfortunately: browser behaviour
> Some popular browsers (e.g. Internet Explorer 7 and Firefox 2)
> requires XML (text/xml and application/xml) with a higher quality
> than HTML. Don't ask me, why a document viewer requests first of all
> a media type intended for machine to machine communication. Opera 9
> for example is more intelligent here (IMO).
>
> Should the JAX-RS consider this (e.g. prefare HTML before other
> MediaTypes, if the developer wants this)? I think, than this could
> be a switch in the ApplicationConfig. It is also possible to ignore
> this in JAX-RS and let this problem be solved by the environment (a
> ServletFilter for example, which can change the quality).
>
I would prefer to leave that to a filter. I could see an application
actually preferring XML but being able to use HTML and wouldn't want
to mess with that.
Marc.
>> [...]
>>
>> Provider for JAXBElement
>> I see a problem for implementing the provider for JAXBElement: I
>> think the proider can not know to which class it should convert the
>> given representation, because the generic type info with the class
>> to convert to is not available in the MessageBodyReader. If
>> readFrom(....) will not get only the the
>> javaMethod.getParameterTypes()[n] as type, but the
>> javaMethod.getGenericParameterType()[n], than the provider can read
>> it.
>>
>> [...]
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net
attached mail follows:
Hi Stephan,
Stephan Koops wrote:
> Hello,
>
> *Visibility of resource methods and locators*
> Are non public (sub) resource methods and sub resource locators allowed?
No. We need to clarify that in the spec.
> The meaning of visibilty limitation is to not allow access from
> everywhere. I think, this should retained here, that means that only
> public (sub) resource methods and sub resource locators are allowed. Or
> is there any advantage to allow also non-public methods here?
>
> *_at_Path*
> Are matrix parameters allowed in @Path? In some cases that makes perhaps
> sense to enforce a given matrix parameter for a method, but this may
> result in non-determinism, e.g.: two methods annotated with
> "path;mp1=xx" and "path;mp2=xx" (both "path" are equal!) with request:
> "path;mp1=xx;mp2=xx". I think it is good to forbid ";" and also "?" and
> perhaps other reserved characters (except "/" of course) in @Path.
>
I agree with this. Also there may be no specific order to matrix
parameters (just like query parameters) so if there were allowed in the
@Path then a complex matching algorithm would be required.
Incidentally the RI has a mode to switch of matrix parameter processing
if one really wants to use ';' in a @Path.
> *Provider for JAXBElement*
> I see a problem for implementing the provider for JAXBElement: I think
> the proider can not know to which class it should convert the given
> representation, because the generic type info with the class to convert
> to is not available in the MessageBodyReader. If readFrom(....) will not
> get only the the javaMethod.getParameterTypes()[n] as type, but the
> javaMethod.getGenericParameterType()[n], than the provider can read it.
>
Yes. My preference would be for the isReadable and readFrom methods to
take the Class<?> and Type [*]. This would also solve reading
Collection<MyType> as well.
> *Providers in general*
> Why did we need the annotation @Provider? Does it is not enough to
> implement the interface(s) MessageBodyReader and/or MessageBodyWriter?
What happens if a concrete class implements those interfaces but the
intention is that they should not be exposed? The declaration of
@Provider makes it very explicit on the intent that the concrete class
is a component managed by the JAX-RS runtime.
> The Jersey providers are also not annotated with @Provider.
>
This is because i wanted:
1) Application specific readers/writers to take precedence over Jersey
readers/writers; and
2) Specify an ordering for Jersey readers/writers.
So i am using META-INF/services for Jersey readers/writers to support
the above. However, relevant examples in the Jersey distribution do use
@Provider.
> Must a MessageBodyWriter/MessageBodyReader close the input / output
> stream? The Jersey providers does, but it is not requested in the
> specification or in the javadoc.
>
Can you point to some code? I looked at all the providers in the latest
source and none of them close the InputStream or OutputStream instance
that is passed respectively to the readFrom or writeTo methods.
The intent was that the providers should not have to close or flush the
stream and it would be the responsibility of the caller to do that,
including guarding against potential unintended side-effects if the
callee does close the stream.
> Do you mean, every container must provide support for
> javax.*xml*.transform.Source instead of javax.transform.Source?
>
Yes, nice catch. I have not had time to implement these in Jersey yet.
Paul.
[*] I wish in Java one could do this:
ParameterizedType t = JAXBElement<MyType>.type;
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net