users@jsr311.java.net

Re: Some questions about 0.7 api

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 07 May 2008 10:08:15 -0700

On May 7, 2008, at 5:33 AM, Sergey Beryozkin wrote:
>
> >>
> > In your example is getBar meant to be a resource method ? If so then
> > the Type parameter would be the whatever you get back from
> > Method.getGenericReturnType()
>
> In which cases Field.getGenericType() would be called (something
> that JavaDocs refer to) ?
>
If you were building a composite reader/writer that uses other reader/
writers to [de]serialize an entity then you might use
Field.getGenericType to get the type of a field within the entity class.

> >>
> >> 2. RuntimeDelegate.createEndpoint(ApplicationConfig ac, Class<T>
> >> endpointType);
> >>
> >> If it's JAX-RS then what is the value of T ?
> >>
> > We don't require support for any particular value of T. Jersey
> > supports a variety including JAX-WS Provider, Grizzly adaptor, LW
> http
> > server.
>
> I don't quite understand the purpose of this method then. The JAX-RS
> spec says that
> it's the only portable way to publish the endpoint. Suppose CXF
> users would like to try the code they're running with CXF
> against Jersey and they don't have JAX-WS involved.
>
What types of endpoints do you support in CXF ?

> There's a CXF specific way to create an endpoint and I thought that
> they may want to choose instead :
>
> RuntimeDelegate.createEndpoint(new ApplicationConfigImpl(), clazz)...
>
> But I don't quite get what T should we use in CXF. Seems like using
> JAX-WS Provider is the only portable value of T but only when people
> would also like to have JAX-WS annotations supported ?
>
Using JAX-WS Provider for T would provide portability between all
implementations that support that type of endpoint but we don't want
to require all implementations to support JAX-WS Provider.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.