Return-Path: 
 <cxf-dev-return-3157-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 84428 invoked from network); 12 May 2007 09:09:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 12 May 2007 09:09:23 -0000
Received: (qmail 14035 invoked by uid 500); 12 May 2007 09:09:29 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 14001 invoked by uid 500); 12 May 2007 09:09:29 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 13987 invoked by uid 99); 12 May 2007 09:09:29 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 May 2007 02:09:29 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Received: from [62.221.12.33] (HELO emea-smg1.iona.com) (62.221.12.33)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 May 2007 02:09:21 -0700
Received: from emea-ems1.ionaglobal.com (dutec.ie [10.2.1.125])
	by emea-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
 l4CA53AJ002935
	for <cxf-dev@incubator.apache.org>; Sat, 12 May 2007 10:05:03 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Determining the Features applied to an endpoint,
 from ServerLifeCycleListener.startServer()
Date: Sat, 12 May 2007 10:08:59 +0100
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FDC7@emea-ems1.IONAGLOBAL.COM>
In-reply-to: <7b774c950705111423p4822fbbclfc53e15428545fa0@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Determining the Features applied to an endpoint,
 from ServerLifeCycleListener.startServer()
Thread-Index: AceUEqdC2EQptqZXQNSHH3dFxuqw9gAXVrWw
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

> -----Original Message-----
> > > > By the mechanism being specific to JAX-WS, I meant that
> > > this frontend
> > > > provides the only way of wiring features in from configuration.
> > > >
> > > > I didn't realize that an analogous <simple:server>=20
> approach can be=20
> > > > used with the simple frontend. Can you point me at a test/demo?
> > >
> > >
> > > I haven't actually supported the <simple:server> syntax yet.
> > > I was simply drawing a distinction between EndpointImpl and=20
> > > *ServerFactorys. The one produces Endpoints. The other produces=20
> > > Servers. Hence their names :-)
> >
> >
> > Would the scehma for <simple:server> be that different from=20
> > <jaxws:endpoint>, or would they be close to identical?
> >
> > If the latter, IMO it would make more sense to have a=20
> single generic=20
> > endpoint bean type that's common to both frontends.
>=20
>=20
> They're close to identical. However, the point is that you=20
> can use an <endpoint> to inject an Endpoint and a <server> to=20
> inject a Server.=20


Well our JAX-WS endpoint impl (i.e. org.apache.cxf.jaxws.EndpointImpl)
holds a reference internally to a Server instance, so if the injection
was to occur in the first instance into the Server instance, then the
Feature setter and getter on EndpointImpl could just look like:

    public List<AbstractFeature> getFeatures() {
        return getServer().getFeatures();
    }

    public void setFeatures(List<AbstractFeature> features) {
        getServer().setFeatures(features);
    }

So regardless of the choice of frontend, the config values would be
wired into the underlying Server instance, which could then be accessed
via the JAX-WS Endpoint if the user wishes.

Similarly on the client-side, the JaxWsClientProxy holds a reference to
the Client instance, so if the injection was to occur in the first
instance into the Client instance, it could be generic across the JAX-WS
and simple frontends.=20


> I don't think its appropriate to really=20
> promote the <server> syntax for JAX-WS because I think JAX-WS=20
> users will want to interact with the JAX-WS Endpoint and its APIs.


But we already use <jaxws:client> when the JAX-WS terminology would be
more like "proxy" instead of "Client".

So it wouldn't necessarily be inconsistent to use "server" in the JAX-WS
case.

Or we could come up with different more neutral synonyms for
client/proxy and server/endpoint.

Cheers,
Eoghan