Hi
May be we can settle on just extending ApplicationConfig with getAddress()
and let users do
RuntimeDelegate.createEndpoint(appConfig, null) which, if supported, result in the endpoint capabale of servicing requests being immediately created ? Or just have RuntimeDelegate.createEndpoint(appConfig) and get rid of the second param;
I personally have no much problems with reusing JAXWS Endpoint interface but it's likely to be somewhat controversial :
1. It will likely affect the image so to say of the RI, even though RI will still be all about RESTful services - no problem for CXF though :-). For some users it will conflict with the idea that Restful services basically do not mesh at all with WS-* services...
2. Perhaps it might be a bit late to decide how RESTful implementations of the existing Endpoint interface should react to various Endpoint method invocations even though it might be obvious...
IMHO
RuntimeDelegate.createEndpoint(ApplicationConfig, null)
is a reasonable compromise, at a later stage either a new Endpoint interface might be introduced ir the reuse of the existing one can be debated further.
I basically see RuntimeDelegate.createEndpoint(ApplicationConfig) as the basis for a JAX-RS portability, hence I'm interested in seeing it updated...
Cheers, Sergey
----- Original Message -----
From: "Marc Hadley" <Marc.Hadley_at_Sun.COM>
To: <users_at_jsr311.dev.java.net>
Sent: Thursday, May 29, 2008 7:42 PM
Subject: Re: RuntimeDelegate.createEndpoint()
On May 29, 2008, at 2:35 PM, Bill Burke wrote:
> I don't plan on using it. Please don't make it a requirement.
>
It would have to be an optional method same as the current method.
Marc.
> 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
>
>
> ---------------------------------------------------------------------
> 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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland