beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Schoettger <>
Subject Re: Service control free threading cleanup...
Date Tue, 26 Jul 2005 21:38:40 GMT
Thank makes sense, I actually had some questions about why it was the way it 
was. I'll create a JIRA issue for this enhancement (modification of the 
service control interface to allow for user defined handlers) and add the 
relevant portions of this thead to it.

- Chad

On 7/26/05, Daryoush Mehrtash <> wrote:
> Chad,
> The ThreadLocal was primarily designed to handle the
> getInputHeader/setOutputHeader interface of the Service Control. As
> you pointed out the Controls depends on its container to maintain a
> single threaded environment, which means the thread safety concern has
> added unnecessary complication. I don't have problem removing this
> code.
> IMHO though, the problem is actually in the interface of the service
> control. I think it is worth while to bring this up and see if there
> are any other suggestions on this.
> The problme that I see is that getInputHeader/setOutputHeader doesn't
> really make sense. Headers should be responsibility of Handlers and
> should not be concern of the service control. For instance, let's
> assume headers are to be used as message checksum. With the current
> interface this is impossible to do since the client would not have
> access to the Soap message to generate the checksum. What you need is
> a user defined Handler that is installed in the processing chain
> such that it would add the header elements based on the checksum of
> the whole message, or validate the message checsum for incomming
> messages.
> JSR 181 defines the similar functionality on the server side that we
> can use as a model. My suggestion would be to adopt the same model
> which menas to add annotations for defining Handlers and removing the
> getInputHeaders/setOutputHeaders interface all together. I think
> this would solve your concern and also make the interface of the
> service control usable.
> Daryoush
> On 7/26/05, Chad Schoettger <> wrote:
> > Currently the service control is coded to be able to be used in a
> > free-threaded manner (such as from a servlet) which is not the use 
> pattern
> > for Beehive controls. Over the next couple of days I would like to do 
> some
> > cleanup in the service control so it will conform more closely to the 
> usage
> > patterns of Beehive controls. The modifications I would like to propose 
> are:
> >
> > 1) Remove the Thread.locals from the HeaderHandler class of the control.
> > 2) Add onAquire() and onRelease() control event handlers to the service
> > control (see jdbc control for examples of these)
> > 2a) Move the invocation of the initialize() method from the invoke() 
> method
> > of the control to the onAquire() method
> > 2b) Do any control cleanup in the onRelease() method
> > 3) Add a cache for Call objects created by the control, and the logic
> > necessary to resuse the cached Calls.
> >
> > Anything else I may be missing or anyone would like to see?
> >
> > - Chad
> >
> >
> --
> Daryoush
> Weblog:

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