beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Schoettger <chad.schoett...@gmail.com>
Subject Re: Design proposal for enhanced JAX-RPC handler functionality for the service control
Date Fri, 29 Jul 2005 14:35:01 GMT
In this particular case, since the @MessageHandlers annotation would be 
processed at runtime we will need to use the service's HandlerRegistry to 
register the handlers. This is done by adding HandlerInfo objects to the 
handler chain. HandlerInfo objects hold three pieces of data: the handler 
class, a Map which contains handler config information and a list of headers 
which the handler is interested in.

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

- Chad


On 7/28/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> 
> > The MessageHandlers annotation in my original mail was based on the 
> JSR181
> > annoation, but I decided to remove several fields which really didn't 
> seem
> > to translate well to the client side and use with the dynamic invocation
> > invocation interface. Specifically the 'roles' and 'name' attribute 
> really
> > didn't seem to have any use for this case.
> 
> Why do you think the client side is different than the server side?
> It seems to me that both side should be symetrical.
> 
> 
> Daryoush
> 
> On 7/28/05, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> > Daryoush -
> >
> > The MessageHandlers annotation in my original mail was based on the 
> JSR181
> > annoation, but I decided to remove several fields which really didn't 
> seem
> > to translate well to the client side and use with the dynamic invocation
> > invocation interface. Specifically the 'roles' and 'name' attribute 
> 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 
> 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) 
> to
> > > > reuse the javax.jws.HandlerChain and 
> 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 
> 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 
> functionality
> > > > for
> > > > > the service control
> > > > >
> > > > > As discussed in a previous email thread on this list (Service 
> control
> > > > free
> > > > > threading cleanup) I would like to make a design proposal for 
> 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 (see
> > > > source
> > > > > tree) which can add SOAP headers to outgoing messages and SOAP
> > > > retrieve
> > > > > headers from incoming messages. There are two service control 
> API's
> > > > which
> > > > > support this: Element[] getInputHeaders() and void
> > > > > setOutputHeaders(Element[])
> > > > >
> > > > > I propose that these two API's be removed as well as the 
> 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 be
> > > > able to
> > > > > define this on a per method basis?
> > > > >
> > > > > - Chad
> > > >
> > > >
> > > >
> > >
> >
> >
> 
> 
> --
> Daryoush
> 
> Weblog: http://perlustration.blogspot.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message