I don't plan on using it. Please don't make it a requirement.
Marc Hadley wrote:
> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com