On May 29, 2008, at 1:51 PM, Bill Burke wrote:
> I'm pretty much against any ties to JAX-WS. One of the reasons
> people find REST so enticing is that it isn't tied to WS-*.
>
I agree in principle but the JAX-WS Endpoint class does have
everything we'd need and doesn't in itself drag in all the WS-* stuff.
It would be hard to justify adding a mostly identical class rather
than reusing the existing one.
Marc.
> Sergey Beryozkin wrote:
>> Hi
>> I was referring to a possibility of introducing a new JAX-RS
>> specific Endpoint interface...didn't think about a possibility of
>> reusing the existing jaxws interface - perhaps, as you said the
>> direct dependency on JAX-WS in SE 5.0 would be a problem...
>> Cheers, Sergey
>> On May 29, 2008, at 11:18 AM, Sergey Beryozkin wrote:
>> >
>> > IMHO there's something not right with the current >
>> RuntimeDelegate.createEndpoint().
>> >
>> > The problem is that two goals are aimed at here.
>> > First, the spec is talking about preprocessing some info
>> available > from the ApplicationConfig. ApplicationConfig is
>> supposed to be a > portable way to submit a user's configuration
>> to the underlying > runtime. But, it won't actually work, unless
>> say, other > implementations, support a Grizzly Adapter interface.
>> >
>> > To me it seems like there's no portabel way for a user to submit
>> an > ApplicationConfig.
>> >
>> Sort of. Its portable provided both implementations support the
>> same type but I know what you mean.
>> >
>> > I'd really like to have either
>> >
>> > RuntimeDelegate.createEndpoint(new ApplicationConfigImpl())
>> >
>> What type would that method return ? javax.xml.ws.Endpoint ? See
>> below for more on this.
>> >
>> > or be able just to use the existing method as
>> >
>> > RuntimeDelegate.createEndpoint(new ApplicationConfigImpl(), null)
>> >
>> > For ex, in CXF, Neither JAX-RS impl nor the nor the user writing
>> a > mainline code know about the existense of Jetty, so it's kind
>> of > unclear to me why, for users being to provide their config
>> through > ApplicationConfig they have to do
>> >
>> > JettySpecificInterface jetty =
>> RuntimeDelegate.createEndpoint(new > ApplicationConfigImpl(),
>> JettySpecificInterface.class);
>> > jetty.start(http://foo);
>> >
>> >
>> > I'd prefer to have ApplicationConfig extended to have
>> >
>> > 1. most obvious property :
>> > ApplicationConfig.getAddress()
>> >
>> > and RuntimeDelegate.createEndpoint changed to
>> >
>> > 2. RuntimeDelegate.createEndpoint(ApplicationConfig ac, >
>> MultivaluedMap<String, String> adaptorProperties)
>> >
>> > with optional adaptorProperties intended for a stack-specific >
>> underlying (transport/server) engines
>> >
>> > and then have
>> >
>> > 3. Endpoint e = RuntimeDelegate.createEndpoint(ApplicationConfig);
>> >
>> You mean javax.xml.ws.Endpoint ? That could work, only issue is
>> that in SE 5.0 we'd then have a direct dependency on the JAX-WS API
>> - not an issue in SE 6.0. This would be less flexible but more
>> portable I guess.
>> >
>> > (something along the line of what Bill suggested)
>> >
>> > and then have
>> >
>> > e.start/stop/getApplicationConfig()/etc....
>> >
>> I guess we could define a specific property name for
>> ApplicationConfig in Endpoint.getProperties().
>> Marc.
>> >
>> > ----- Original Message -----
>> > From: "Marc Hadley" <Marc.Hadley_at_Sun.COM <mailto:Marc.Hadley_at_Sun.COM
>> >>
>> > To: <users_at_jsr311.dev.java.net <mailto:users_at_jsr311.dev.java.net>>
>> > Sent: Thursday, May 08, 2008 12:57 AM
>> > Subject: Re: RuntimeDelegate.createEndpoint()
>> >
>> > Right, so code is portable between implementations that support the
>> > same types of endopints.
>> >
>> > On May 7, 2008, at 1:38 PM, Bill Burke <bburke_at_redhat.com <mailto:bburke_at_redhat.com
>> >> wrote:
>> >
>> > > Please tell me how this is portable? JAX-RS implementation
>> needs to
>> > > support endpoint interface.
>> > >
>> > > Marc Hadley wrote:
>> > >> On May 7, 2008, at 10:23 AM, Bill Burke wrote:
>> > >>>
>> > >>> Can you elaborate on what createEndpoint() is supposed to
>> do? Is
>> > >>> it a way for somebody to programmatically add resources?
>> > >>>
>> > >>> Your recent conversation with Sergey confused me...
>> > >>>
>> > >> Sorry about that. Its a way to create an instance of an endpoint
>> > >> class in a Java SE environment. E.g. if you wanted to use
>> Grizzly
>> > >> to publish a JAX-RS application then you'd do something like:
>> > >> ApplicationConfig config = new MyApplicationConfig(...);
>> > >> RuntimeDelegate rd = RuntimeDelegate.getInstance();
>> > >> Adapter a = rd.createEndpoint(config, Adapter.class);
>> > >> SelectorThread st = GrizzlyServerFactory.create(
>> > >> “http://127.0.0.1:8084/”, a);
>> > >> where Adaptor is a Grizzly-defined interface. The createEndpoint
>> > >> method is generic so it can be used for a variety of HTTP
>> servers.
>> > >> Jersey supports Grizzly, the LW HTTP server built into Sun's
>> SE 6.0
>> > >> runtime and JAX-WS Provider but implementations are free to
>> decide
>> > >> what types they want to support.
>> > >> Marc.
>> > >> ---
>> > >> Marc Hadley <marc.hadley at sun.com>
>> > >> CTO Office, Sun Microsystems.
>> > >> >
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net <mailto:users-unsubscribe_at_jsr311.dev.java.net
>> >
>> > >> For additional commands, e-mail: users-
>> help_at_jsr311.dev.java.net <mailto:users-help_at_jsr311.dev.java.net>
>> > >
>> > > --
>> > > Bill Burke
>> > > JBoss, a division of Red Hat
>> > > http://bill.burkecentral.com
>> > >
>> > >
>> > > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net <mailto:users-unsubscribe_at_jsr311.dev.java.net
>> >
>> > > For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>> <mailto:users-help_at_jsr311.dev.java.net>
>> > >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net <mailto:users-unsubscribe_at_jsr311.dev.java.net
>> >
>> > For additional commands, e-mail: users-help_at_jsr311.dev.java.net <mailto:users-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
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net <mailto:users-unsubscribe_at_jsr311.dev.java.net
>> >
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net <mailto:users-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
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.