Mailing-List: contact beehive-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <beehive-dev@incubator.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of chad.schoettger@gmail.com
 designates 64.233.162.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=l75w68MtH0+rcHGg0imv2O4ZfN8CDaJgjAO0/L/E+dCP7fsXyDliA9exSvRn5bi+3alKTki8XQ6iUDRuQOnUzzPoLNDdyQ2Ngqrsd8nhHLqSfBn2n6V/2YeIGrcW8MGd0zi2vOV0ANb3NSA1djD8wvo/huQViqV4I18MAMuVvto=
Message-ID: <ecaa4efd050729073544699894@mail.gmail.com>
Date: Fri, 29 Jul 2005 08:35:01 -0600
From: Chad Schoettger <chad.schoettger@gmail.com>
Reply-To: Chad Schoettger <chad.schoettger@gmail.com>
To: Daryoush Mehrtash <dmehrtash@gmail.com>
Subject: Re: Design proposal for enhanced JAX-RPC handler functionality for
 the service control
Cc: Beehive Developers <beehive-dev@incubator.apache.org>
In-Reply-To: <e5b8e979050728144761744a7f@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9535_9384733.1122647701735"
References: <4B2B4C417991364996F035E1EE39E2E1027C2705@uskiex01.amer.bea.com>
	 <e9ac835405072719175af73101@mail.gmail.com>
	 <ecaa4efd05072807521669cd80@mail.gmail.com>
	 <e5b8e979050728144761744a7f@mail.gmail.com>

------=_Part_9535_9384733.1122647701735
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In this particular case, since the @MessageHandlers annotation would be=20
processed at runtime we will need to use the service's HandlerRegistry to=
=20
register the handlers. This is done by adding HandlerInfo objects to the=20
handler chain. HandlerInfo objects hold three pieces of data: the handler=
=20
class, a Map which contains handler config information and a list of header=
s=20
which the handler is interested in.

I removed the 'handler name' and 'roles' elements from the MessageHandlers=
=20
annotation because we wouldn't be able to use them when registering the=20
handler dynamically.

- Chad


On 7/28/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
>=20
> > The MessageHandlers annotation in my original mail was based on the=20
> JSR181
> > annoation, but I decided to remove several fields which really didn't=
=20
> seem
> > to translate well to the client side and use with the dynamic invocatio=
n
> > invocation interface. Specifically the 'roles' and 'name' attribute=20
> really
> > didn't seem to have any use for this case.
>=20
> Why do you think the client side is different than the server side?
> It seems to me that both side should be symetrical.
>=20
>=20
> Daryoush
>=20
> On 7/28/05, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> > Daryoush -
> >
> > The MessageHandlers annotation in my original mail was based on the=20
> JSR181
> > annoation, but I decided to remove several fields which really didn't=
=20
> seem
> > to translate well to the client side and use with the dynamic invocatio=
n
> > invocation interface. Specifically the 'roles' and 'name' attribute=20
> really
> > didn't seem to have any use for this case.
> >
> > I'll take a look at adding a HandlerChain annotation and post what I=20
> come up
> > with in this thread.
> >
> > - Chad
> >
> >
> > On 7/27/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > >
> > > Daryoush--
> > >
> > > At first glance, I'd argue that the Beehive web service control
> > > shouldn't be tightly coupled to the JSR 181 standard and that we
> > > should define our own annotations for clients wishing to use these
> > > features when calling web services.
> > >
> > > The reason for this is just loose coupling. The JSR 181 spec wasn't
> > > written with the service client side in mind (as far as I know), so
> > > I'd advocate building this so that the client side and server
> > > authoring model can be evolved independently.
> > >
> > > That's my $0.02.
> > >
> > > Eddie
> > >
> > >
> > > On 7/27/05, Daryoush Mehrtash <dmehrtas@bea.com> wrote:
> > > > My suggestion is (unless there is a good reason why we should not)=
=20
> to
> > > > reuse the javax.jws.HandlerChain and=20
> javax.jws.soap.SOAPMessageHandlers
> > > > annotation. It would be nice not to invent new annotations if there
> > > > are already defined.
> > > >
> > > > We may also be able to reuse the handler code of the WSM in the=20
> service
> > > > control.
> > > >
> > > > Daryoush
> > > >
> > > > > -----Original Message-----
> > > > > From: Chad Schoettger [mailto:chad.schoettger@gmail.com]
> > > > > Sent: Wednesday, July 27, 2005 3:01 PM
> > > > > To: Beehive Developers
> > > > > Subject: Design proposal for enhanced JAX-RPC handler=20
> functionality
> > > > for
> > > > > the service control
> > > > >
> > > > > As discussed in a previous email thread on this list (Service=20
> control
> > > > free
> > > > > threading cleanup) I would like to make a design proposal for=20
> adding
> > > > > enhanced JAX-RPC handler functionality to the service control.
> > > > >
> > > > > One of the primary goals of this change would be to allow service
> > > > control
> > > > > users to define their own JAX-RPC handler chains for a service
> > > > control.
> > > > > Currently the service control only supports the HeaderHandler (se=
e
> > > > source
> > > > > tree) which can add SOAP headers to outgoing messages and SOAP
> > > > retrieve
> > > > > headers from incoming messages. There are two service control=20
> API's
> > > > which
> > > > > support this: Element[] getInputHeaders() and void
> > > > > setOutputHeaders(Element[])
> > > > >
> > > > > I propose that these two API's be removed as well as the=20
> HeaderHandler
> > > > > class.
> > > > >
> > > > > The API's would be replaced with a new annotation in the
> > > > ServiceControl
> > > > > interface:
> > > > >
> > > > > public @interface HandlerConfigParams {
> > > > > String name();
> > > > > String value();
> > > > > }
> > > > >
> > > > > public @interface MessageHandler {
> > > > > Class handlerClass();
> > > > > HandlerConfigParams[] configParams() default {};
> > > > > String[] headers() default {};
> > > > > }
> > > > >
> > > > > @Retention(RetentionPolicy.RUNTIME)
> > > > > @Target({ElementType.TYPE})
> > > > > public @interface MessageHandlers {
> > > > > MessageHandler[] value();
> > > > > }
> > > > >
> > > > > If this optional annotation is set service control would add the
> > > > handlers
> > > > > to
> > > > > the HandlerRegistry at runtime. I'm thinking this would be a
> > > > class-level
> > > > > annotation for the service control - would it also be useful to b=
e
> > > > able to
> > > > > define this on a per method basis?
> > > > >
> > > > > - Chad
> > > >
> > > >
> > > >
> > >
> >
> >
>=20
>=20
> --
> Daryoush
>=20
> Weblog: http://perlustration.blogspot.com/
>

------=_Part_9535_9384733.1122647701735--