On May 30, 2008, at 12:01 PM, Sergey Beryozkin wrote:
>
> Perhaps the second parameter can be treated as a endpoint interface
> class ? In that case the return value would be the endpoint
> interface, it could be either a javax.xml.ws.Endpoint or some other
> endpoint interface JAX-RS might introduce later...Perhaps not even a
> class but a type-safe enum value can be passed in which would
> represent the name of the endpoint class to avoid a direct
> dependency on JAX-WS api.
But that's exactly what we have now, e.g. you could do:
javax.xml.ws.Endpoint = delegate.createEndpoint(applicationConfig,
javax.xml.ws.Endpoint.class);
(assuming the impl supports javax.xml.ws.Endpoint as an endpoint type).
The reason for the current design is to avoid a dependency on a
particular type while still offering a standard way to talk to the
delegate endpoint factory.
> Perhaps it might be worth giving more thought to the idea of
> introducing a new interface. While it would resemble the jaxws one,
> it can have more useful JAX-RS specific methods on it, etc... In the
> end of the day people can write RESTful services with JAX-WS
> Provider<Source> just fine (we ceratinly have some experience),
> without even sprinkling the code with annotations :-), but it didn't
> stop the JAX-RS experts to come up with a new/fresh idea, even at
> the cost of duplicating some of the functionality which can be
> achieved with JAX-WS today...
>
Similarly you can do:
javax.xml.ws.Provider = delegate.createEndpoint(applicationConfig,
javax.xml.ws.Provider.class);
and then use the Provider with an Endpoint to publish the application
(again, assuming the delegate impl supports Provider as an endpoint
type).
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.