Yes, that JAX-WS comparison was a little weak ;)
I was thinking about the java mapping for XML schema built-in types.
Without the need to represent it as XML, just the plain value
representation. See JAXB 2.0, section 6.2.
This would at least follow a common way of representing java types as
string values.
- Heiko
On Tue, 2007-12-04 at 10:21 -0500, Marc Hadley wrote:
> On Dec 4, 2007, at 5:04 AM, Heiko Braun wrote:
> >
> > Maybe we should require support for simple type payload,
> > that covers all std. java types. Similiar to what JAX-WS already
> > supports.
> >
> I'm not sure I understand what you are suggesting, could you elaborate
> a bit ?
>
> Thanks,
> Marc.
>
> >
> > On Tue, 2007-12-04 at 05:00 -0500, Liu, Jervis wrote:
> >>
> >>> -----Original Message-----
> >>> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> >>> Sent: 2007年12月3日 22:50
> >>> To: dev_at_jsr311.dev.java.net
> >>> Subject: Re: JSR311: The best practice to return primitive types
> >>> from a
> >>> RESTful service?
> >>>
> >>> On Dec 3, 2007, at 2:37 AM, Liu, Jervis wrote:
> >>>>>> a). in JSR-311 section 3.1.2, "An implementation MUST include
> >>>>>> pre-
> >>>>>> packaged EntityProvider implementations for the following Java
> >>>>>> and
> >>>>>> media type combinations:", add the support for Java Primitive
> >>>>>> types:
> >>>>>>
> >>>>>> Java primitive types All text media types (text/*).
> >>>>>>
> >>>>>> But with an statement that returning a fine grained primitive
> >>>>>> type
> >>>>>> is not a recommended practice.
> >>>>>>
> >>>>>> Essentially this means a JSR-311 runtime implementation needs to
> >>>>>> provide a PrimitiveEntityProvider to read and write primitive
> >>>>>> types
> >>>>>> to/from entity body using text/plain content type, same as what
> >>>>>> we
> >>>>>> do with String.
> >>>>>>
> >>>>>> b). Do not provide any support for Java Primitive types but
> >>>>>> explicitly stated in JSR-311 section 3.1.2 that no default
> >>>>>> support
> >>>>>> for returning Java Primitive types is because this is not a
> >>>>>> recommended practice. But if users really want to do this, they
> >>>>>> really understand the design choice they have made, they can do
> >>>>>> this
> >>>>>> by registering their own PrimitiveEntityProvider on the JSR-311
> >>>>>> container.
> >>>>>>
> >>>>> c) Use one of the primitive type wrapper classes (e.g.
> >>>>> java.lang.Integer) along with a corresponding MessageBodyWriter.
> >>>>>
> >>>>> Thinking about it we could remove the need for a
> >>>>> MessageBodyWriter by
> >>>>> requiring the runtime to use the toString method when there's no
> >>>>> MessageBodyWriter. The problem with that is that Object provides a
> >>>>> default toString so it would be easy for an application to exhibit
> >>>>> unexpected behavior if the MessageBodyWriter they provide isn't
> >>>>> picked
> >>>>> up for some reason. Essentially a class of error (missing
> >>>>> MessageBodyWriter) would be hard to detect.
> >>>>>
> >>>>
> >>>> Hi Marc, did you suggest that the JSR-311 runtime provides a
> >>>> behavior such that when there is no MessageBodyWriter selected for
> >>>> the return type, Object.toString will be used to form an
> >>>> output( does this also suggest that in the case of no
> >>>> MessageBodyWriter selected, the default output content type is
> >>>> text/
> >>>> plain?).
> >>>
> >>> Yes and no respectively. Yes, I was suggesting use of
> >>> Object.toString
> >>> in the case of no MessageBodyWriter though I'm not convinced its a
> >>> good idea due to the issue I describe above. No, the media type
> >>> would
> >>> still be determined based on the criteria I described in the mail I
> >>> sent last week with the subject "Determining the media type of
> >>> responses".
> >>
> >> [Liu, Jervis]
> >> Agreed. This does not look like a good approach. This is
> >> inconsistent with what you suggested last week (subject
> >> "Determining the media type of responses"): "If the list is empty
> >> an error is signaled via a 406 Not Acceptable.". I do believe a 406
> >> makes more sense when there is MessageBodyWriter selected.
> >>
> >>>
> >>>> Or instead what you meant is defining a pre-packaged
> >>>> MessageBodyWriter in JSR-311 spec to handle primitive types. For
> >>>> the
> >>>> later, I don’t see the difference between this and approach a).
> >>>> Using primitive type wrapper classes is the implementation detail
> >>>> of
> >>>> PrimitiveTypeMessageBodyWriter.
> >>>>
> >>> There's a difference between implementing support for int
> >>> someMethod()
> >>> vs Integer someMethod(). E.g. a primitive type can't be the
> >>> parameterized type of MessageBodyWriter so you have to use the
> >>> primitive wrapper class instead.
> >>>
> >> [Liu, Jervis]
> >> I think we do need to support " int someMethod ()", this make it a
> >> lot easier when people migrating their existing code to JSR-311.
> >> For example, I may have following method in my POJO, it is just a
> >> matter of adding extra JSR-311 annotations then I can expose this
> >> POJO as a RESTful service.
> >>
> >> int getEmployeeAge(String employeeName) {
> >> ...
> >> }
> >>
> >> Have to ask people changing their method signature to Integer
> >> getEmployeeAge(String employeeName) sounds unreasonable. Lets talk
> >> about the implementation details in a JSR-311 runtime a little bit,
> >> I should be able to provide a PrimitiveWrapperMessageBodyWriter as
> >> below:
> >>
> >> public final class PrimitiveWrapperMessageBodyWriter implements
> >> MessageBodyWriter<Object> {
> >>
> >> public boolean supports(Class<?> type) {
> >> //expect a primitive type wrapper class
> >> if (type is a primitive type wrapper class)
> >> return true;
> >> return false;
> >> }
> >>
> >> public void writeTo(Object obj, MediaType m,
> >> MultivaluedMap<String, Object> headers, OutputStream os) {
> >> try {
> >> os.write(obj.toString());
> >> } catch (IOException e) {
> >> //TODO: better exception handling
> >> }
> >>
> >> }
> >> }
> >>
> >> Not sure about Jersey, but this works in CXF because the invoking
> >> result of int getEmployeeAge(String employeeName) is always wrapped
> >> in an Integer as the invoking is done through reflection.
> >>
> >> IMHO the JSR-311 spec section 3.1.2 should state that "An
> >> implementation MUST include pre-packaged EntityProvider
> >> implementations for "Java primitive type wrappers (i.e., Integer)
> >> ". And it is the responsibly of JSR-311 runtime to convert from
> >> Java primitive types to corresponding Java primitive type wrappers
> >> to suit the need of PrimitiveWrapperMessageBodyWriter/Reader.
> >>
> >> Cheers,
> >> Jervis
> >>
> >>> Marc.
> >>>
> >>> ---
> >>> Marc Hadley <marc.hadley at sun.com>
> >>> CTO Office, Sun Microsystems.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>
> >> ----------------------------
> >> IONA Technologies PLC (registered in Ireland)
> >> Registered Number: 171387
> >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> >> Ireland
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>