I agree. createEndpoint seems pretty useless to me. I don't want users
interacting with internal apis. I'm not even sure I want even a
programmatic way to deploy ApplicationConfig. The thing is, you may
have multiple root JAX-RS "endpoints" (not to confuse with
createEndpoint) deployed at different root URIs and different
configuration, port, host, and security settings. A static method just
doesn't cut it for these scenarios.
In general, I hate the usage of all these static methods everywhere, but
I don't see us being able to remove them at this point.
Sergey Beryozkin wrote:
> Hi
>
> 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.
>
> I'd really like to have either
>
> RuntimeDelegate.createEndpoint(new ApplicationConfigImpl())
>
> 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);
>
> (something along the line of what Bill suggested)
>
> and then have
>
> e.start/stop/getApplicationConfig()/etc....
>
>
> Thoughts ?
>
>
> Cheers, Sergey
>
>
> ----- 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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com