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>
> To: <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> 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
> >> 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
> >
>
> ---------------------------------------------------------------------
> 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
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.