Hi
Sanjiva Weerawarana wrote:
>On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote:
>
>
>>In terms of setting up TLS info, I'm interested by the comment that it
>>would be set in the AxisEngine. When we had the conversation about the
>>ThreadContextMigrator interface (which does now exist) I understood
>>that there wasn't any guarantee that there is a single thread in use
>>through the handler chain.
>>
>>
>
>I believe it'll be set in the message receiver just before invoking the
>method right guys? I can't see why it needs to be set earlier.
>
>
Yes that was the final conclusion.
FYI:
Deepal: hi dims
[15:07] Deepal: u there
[15:08] Deepal: I dont think we can move saveTCCL(messageCtx);
in AxisEngine
[15:23] GlenD: dims?
[15:23] GlenD: u there?
[15:26] dims: ping
[15:26] GlenD: hey
[15:26] GlenD: so Deepal and I were chatting about the context stuff
[15:26] dims: yes
[15:26] GlenD: and ended up coming up with a very interesting
idea which we wanted to run past you
[15:26] dims: sure
[15:26] GlenD: I think it's too big a change for now, but it's
pretty cool for a future release
[15:27] dims: we need to make a list of those :)
[15:28] GlenD: the issue is that there's a lot of code
duplication amongst MessageReceivers
[15:28] dims: ah. that one :)
[15:28] GlenD: if we want this setTCCL stuff and the
setCurrentContext stuff to live in the MRs, it's hard to figure out
where to put it so it isn't dup'ed everywhere
[15:29] dims: call back to engine?
[15:29] dims: sorry...go ahead.
[15:29] GlenD: so we're wondering if you could maybe factor it
out into a single AbstractMessageReceiver
[15:29] GlenD: which would do the TCCL/Context stuff, then call
invokeBusinessLogic() but pass only the OperationContext
[15:29] dims: we have one of those
[15:30] dims: AbstractMessageReceiver
[15:30] GlenD: not have separate ones that pass either
(inContext) or (inContext, outContext)
[15:30] GlenD: we do?
[15:30] dims: we need to structure it better
[15:30] Deepal: we have 4 of them :)
[15:30] GlenD: right
[15:30] GlenD: we have 4
[15:30] dims: org.apache.axis2.receivers.AbstractMessageReceiver
[15:31] dims: ah. i see
[15:31] Deepal: and we are thinking of chaning
invokeBusinessLogic signature
[15:31] GlenD: only the lower level ones (AbstractInOnlyMR, etc)
actually have receive()
[15:31] GlenD: the top level one doesn't do anything
[15:31] GlenD: except hold utility methods
[15:31] dims: any cleanup is very welcome! sorely needed in this
area.
[15:31] dims: +1
[15:31] GlenD: so the interesting part is that SOMEONE needs to
know to take the outMessageContext from the operationContext and send it
[15:31] dims: please make sure you handle the spring scenario
[15:31] Deepal: invokeBusinessLogice will take OperationContext
as it argument
[15:32] GlenD: that's the real difference between in and inout
[15:32] dims: and then check isinstanceof?
[15:32] GlenD: we're wondering if there's a way to genericize
that by calling invokeBusinessLogic() and then something like complete()
or doNext()
[15:32] GlenD: but we need to think about it a little more I
think :)
[15:33] dims: yep...
[15:33] dims: pre and post?
[15:34] GlenD: (thinking here)
[15:34] dims: first step is to collapse all 4 into 1
AbstractMessageReceiver?
[15:34] dims: somehow
[15:34] GlenD: that was the thought yes but we're seeing if it
can work....
[15:35] dims: then adjust the calls to invokeBusinessLogic and
maybe call something before it and something after it for special
processing for different MEP's?
[15:36] dims: are we looking for clean code or new feature here?
[15:36] Deepal: I think both :)
[15:37] dims: and the new Feature is?..
[15:37] GlenD: its really mostly clean code
[15:37] GlenD: and a good place to put the common stuff for tls
[15:38] dims: :) ok.
[15:53] GlenD: ok never mind :)
[15:53] GlenD: I think we just came to the conclusion that it's
actually useful to have different abstract Receiver types
[15:54] GlenD: because they're the ones that know the logic for
message processing
[15:54] GlenD: if you had an in/in/out MR, for instance, it
could have processMessage1() and processMessage2() abstract operations
[15:54] GlenD: that's nicer than just relying on a single
invokeBusinessLogic(OperationContext), I think
[15:56] GlenD: So the idea is to coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and
removeThreadContext() on AbstractMessageReceiver
[15:57] GlenD: so developers of new MRs that want TLS
functionality would need to know to call that method, but it sets up
both the classloader and the MessageContext.getCurrentContext()
[16:00] dims has disconnected: Read error: 104 (Connection reset
by peer)
[16:00] dims has joined
[16:01] dims: +1 to "coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and removeThreadContext()"
[16:01] GlenD: great
[16:01] Deepal: +1 for doing that for 1.1
[16:01] dims: sure
[16:02] dims: but again. proposal to mailing list.
[16:07] GlenD: ya
[16:35] GlenD: brb
[16:35] GlenD has disconnected
[16:36] GlenD has joined
[17:13] Deepal: this time hackerthon seems good to me
[17:14] Deepal: finding bugs , improvements
[17:14] Deepal: s/hackerthon/hackarthon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
