[ http://issues.apache.org/jira/browse/BEEHIVE-869?page=all ]
Eddie O'Neil closed BEEHIVE-869:
This feature was completed, and the SC doesn't use ThreadLocal any longer.
Closing.
Service control free threading cleanup
[ http://issues.apache.org/jira/browse/BEEHIVE-869?page=all ]
Eddie O'Neil resolved BEEHIVE-869:
--
Resolution: Fixed
Patch applied in SVN 230690.
Service control free threading cleanup
[ http://issues.apache.org/jira/browse/BEEHIVE-869?page=all ]
Chad Schoettger updated BEEHIVE-869:
Attachment: BEEHIVE-869.txt
BEEHIVE-869.zip
BEEHIVE-869.diff
patches attached
Service control free threading cleanup
[ http://issues.apache.org/jira/browse/BEEHIVE-869?page=all ]
Chad Schoettger reassigned BEEHIVE-869:
---
Assign To: Eddie O'Neil (was: Chad Schoettger)
assigned to Eddie for commit/review.
Service control free threading cleanup
Service control free threading cleanup...
-
Key: BEEHIVE-869
URL: http://issues.apache.org/jira/browse/BEEHIVE-869
Project: Beehive
Type: Bug
Components: System Controls
Versions: TBD
Reporter: Chad Schoettger
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
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
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
