> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > 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/
