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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: http://perlustration.blogspot.com/ >
