[chat log provided by Ajith Ranabahu on axis-dev]
[19:45] *** Apache Axis Framework for web services [19:45] *** [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup : #apache-axis [19:47] *** Jaliya joined #apache-axis [19:51] *** Chinthaka_away joined #apache-axis [19:51] *** Chinthaka_away is now known as Chinthaka [19:56] *** Srinath sets topic for #apache-axis : Apache Axis Framework for web services [Axis2] [20:00]<Ajith> Good morning/evening everybody [20:01]<Deepal> Hi all [20:02] *** gdaniels joined #apache-axis [20:03]<Deepal> hi glen [20:03]<gdaniels> good morning, folks [20:03]<Srinath> hi all [20:03]<Deepal> can we start now [20:03]<Chinthaka> I think so :) [20:03]<Deepal> can I start from phase handlers [20:03]<Deepal> :) [20:04]<Deepal> Glen : can u pls tell me wt really mean by phase [20:04]<Ajith> yeah since glen is here we can clarify that first [20:04]<Deepal> is that logical collection of handlers [20:04]<Srinath> Sanjiva Sir is trying to connect .. but said trouble connecting in :( [20:04]<Ajith> ah [20:04]<Deepal> so then wait until he come [20:05]<Deepal> i mean Dr Snjiva [20:05]<Srinath> I think we got to start he said he is getting no response at all .. [20:06]<Deepal> k [20:06]<FR^2> Oh, it's wednesday again ;-) [20:06]<gdaniels> Deepal: Sure, yes, it's a logical collection of Handlers, which runs in a particular order with respect to a) the other Phases, and b) certain engine tasks like dispatching [20:06]<Deepal> Glen can u pls answer the q that I asked [20:07]<Deepal> how can we ordr handler inside a phase [20:07]<Ajith> aha ... it is a logical group only right? [20:07]<Deepal> i mean order [20:07]<gdaniels> That's a deployment question, Deepal [20:07]<gdaniels> Up to us :) [20:07]<Deepal> Glen : in hander [20:07]<Deepal> there are proprty call [20:07] *** Gabriel_Shear joined #apache-axis [20:07]<Ajith> glen: in the DD what is the order that you specify [20:07]<Deepal> before and after [20:08]<Jaliya> Hi all, [20:08]<gdaniels> We discussed having a few options - 1) deploy this Handler "before" phase X, 2) deploy this handler "in" Phase X, 3) deploy this handler as the FIRST one in Phase X, etc [20:08]<Deepal> wt they really represent [20:08]<gdaniels> Deepal - do you mean "checkPrecondition"/"checkPostcondition"? [20:08]<Deepal> So u mean b4 and after represnt phases [20:09] *** Gabriel_Shear left #apache-axis : [20:09]<Deepal> no Glen In hander there are proproty call beore and afte [20:09]<Deepal> http://wiki.apache.org/ws/FrontPage/Architecture/Deployment [20:10]<Deepal> in this doc u can see that [20:10]<gdaniels> looking [20:10]<Chinthaka> even in http://wiki.apache.org/ws/FrontPage/Axis2 under 1.8 [20:10]<Deepal> 1.6.1 [20:11]<gdaniels> First off, you realize that the stuff in the wiki is just a strawman for now, right? [20:11]<gdaniels> So anything there is subject to change/approval/etc [20:11]<Deepal> hmm [20:11] *** dims joined #apache-axis [20:11]<gdaniels> It looks like this is a swipe at the ordering, but not necessarily what we'll end up with. [20:11]<gdaniels> hi dims! [20:11]<gdaniels> :) [20:12]<Deepal> so wt if we make before and after as Hnaders [20:12]<Jaliya> The idea I have is that, the phase is a logical group of handlers, at the DD we can define any number of phases and the order can be described using before, after etc.. I am right glen? [20:12]<gdaniels> Jaliya: sounds right to me [20:12]<gdaniels> We need to be careful about allowing TOO much flexibility at first [20:12]<Chinthaka> jaliya : its true, but here we are talking abt before and after of handlers [20:12]<Deepal> Jaliya : order phases is discribd in sercer.xml [20:12]<gdaniels> That can get complex [20:13]<gdaniels> But that's the basic idea, yes. [20:13]<Deepal> jaliya : sorry order of phases [20:13]<gdaniels> We need to play with it to make sure it works/is useful enough [20:14]<Jaliya> Yes [20:14]<Deepal> Glen i dinnt get u [20:14]<Srinath> HELP!! is their any HTTP bridge IRC (for Dr Sanjiva ) [20:15]<Chinthaka> Srinath : Miranda ? [20:15]<Jaliya> I think that also may not use 80 [20:15]<gdaniels> If we allow too many options, Deepal (deploy this handler before this one, but after this one, and three before this one's cousin, etc.), it can get confusing for the deployer and hard to implement for us. We need to find the right balance between expressivity and minimalism - keep it small but not too small. [20:17]<Ajith> glen : so do you have any control over how the handlers are ordered INSIDE the phase then?? [20:17]<gdaniels> Ajith: That's up to us to decide. :) I think a little, like saying "make this the first handler in phase X", but maybe not to the level of "this one, then this one, then that one..." [20:19]<Ajith> aah [20:19]<Ajith> So it means we have full control over the order of phases but not the order of handlers inside the phase [20:19]<Chinthaka> I think that what achieved thru phaseFirst and phaseLast [20:19]<Jaliya> One more question we had was that, the bounderies of a phase, can a handler in one phase be interspersed with another pahse [20:20]<gdaniels> Chinthaka: right [20:20]<Ajith> yep that is another issue [20:20]<Ajith> my reckoning was that they should not intersect [20:21]<Chinthaka> Ajith : didn't get u [20:21]<gdaniels> no, I think each handler is in exactly one phase [20:21]<Srinath> any other options than Miranda ? [20:21]<gdaniels> Miranda? [20:21]<Jaliya> glen: Ah ok [20:22]<Srinath> glen:sorry Any HTTP bridge for IRC [20:22]<Deepal> Glen : phase property of a hander is optionl now [20:22]<Chinthaka> Srinath : XChat is there, but I haven't tried that :( [20:23]<Deepal> wt if we make it mandatory [20:23]<Chinthaka> can i say that the before and after attributes refer either to a handler or to a phase ? [20:23]<Deepal> then user can speifically say that this hander belong to this pahse etc.. [20:24]<Deepal> Chinthak : I think it is difficult to implement :( [20:24]<Deepal> sorry specifically not speifically [20:25]<Chinthaka> deepal, y ? its just another URI [20:25]<gdaniels> (sorry was trying to help sanjiva) [20:25]<gdaniels> Chinthaka: I don't see why not... [20:25]<gdaniels> Chinthaka: as long as it doesn't conflict with anything else you claim in the DD [20:26]<Deepal> Chinthka : I think we can [20:26]<Ajith> Chinthaka : Sorry I had to take a call. What I meant was phases should not intersect ! [20:26]<gdaniels> Deepal: I don't think it should be mandatory to specify phase, but am not sure yet. There can be a default [20:27]<Ajith> Glen : you say each hander is in only one phase? should it be [20:27]<Deepal> that means if user dosent specify the phase its belong to default ? [20:27]<Srinath> glen:but if we let before after refer to handlers it might messay.. as usulally the phase is the only well known thing [20:27]<Ajith> I mean how about the logging handler [20:27]<gdaniels> Deepal: yes, something like that [20:27]<gdaniels> Ajith: each handler type can be in more than one phase [20:27]<gdaniels> definitely [20:28]<gdaniels> but for each individual handler configuration, I think maybe it's only in one phase.... but maybe not! :) [20:29] *** Jaliya left #apache-axis : [20:30]<Ajith> Ok So you mean that you find each "handler instance" is uniquely bound to a phase [20:30]<gdaniels> right [20:33]<Chinthaka> : [20:34] *** sanjiva joined #apache-axis [20:34]<Deepal> so then before and after can reprsent either pahse or hander ? [20:34]<sanjiva> hi guys [20:34]<Deepal> hi sir [20:34]<Ajith> ok this seems like a great improvement from where we were [20:34]<gdaniels> Deepal: TBD [20:34]<Chinthaka> at last [20:34]<Ajith> hi [20:34]<Srinath> Hi Sir .. got in at last:) [20:34]<sanjiva> managed to run my old apache soap tunnel on an IBM machine and now connected thru that .. old hack comes thru again :) [20:35]<Srinath> :D [20:35]<sanjiva> sorry to be late! [20:35]<gdaniels> so we're talking phased handlers, sanjiva [20:35]<sanjiva> ok cool - keep going I'll catch up [20:35]<gdaniels> in particular how to deploy handlers into phases [20:35]<Srinath> it is bit blurred yet ..:) [20:35]<gdaniels> ordering, etc [20:36]<gdaniels> one thing we need to decide is what kind of state model we want for handlers in Axis2 [20:36]<sanjiva> doesn't stateless work?? I like that model ;-) [20:36]<gdaniels> Axis has scopes for handlers just like for service objects - request, application, session [20:36]<Deepal> sir did u go thoruh the mails abt pahse handers [20:36]<gdaniels> sanjiva: it does, but the other patterns can be very handy. [20:37]<gdaniels> we could decide to just do stateless and keep all state external if we want [20:37]<sanjiva> other patterns? [20:37]<sanjiva> I prefer the keep state external approach because of scalability, perf and ease of arch/impl [20:37]<gdaniels> yeah, in Axis when you name a handler and then re-use it elsewhere you get the SAME object [20:37]<sanjiva> "KISS" @ work [20:37]<sanjiva> across all services or per invocation? [20:37]<Srinath> yap I am +1 for statelss too [20:38]<gdaniels> per invo, but you can also set it to application and it's a singleton [20:38]<gdaniels> I'm ok with stateless, but we need to make sure that the options bag for each handler is correctly available to getOption/setOption [20:38]<sanjiva> ah scope=app or scope=session kind of thing for handlers too? [20:38]<gdaniels> sanjiva: yep [20:38]<Ajith> since handlers are stateless it would not matter [20:39]<sanjiva> Yes handlers should get the message context to which u can set stuff by name/value pairs .. is that what u mean glen? [20:39]<gdaniels> re: options, I mean when you deploy <handler name="foo"><parameter name="p1" value="5"/></handler> [20:39]<Srinath> we can keep everything in message Ctx .. give differant scope accsess e.g. Gloabl ctx, sessionctx,MessageCtx [20:39]<gdaniels> getOption("p1") in that [20:39]<gdaniels> handler should work [20:40]<sanjiva> Srinath: right .. in addition to message-level context there's clearly context of the service associated per "session" and maybe even globally across all sessions. That's like the servlet state model .. which IMO we should follow because that's proven and scales well and is easy for users [20:41]<sanjiva> (after all it was copied frm the msft mode in ASPs ;-)) [20:41]<sanjiva> s/mode/model/ [20:41]<sanjiva> glen: +1 [20:41]<sanjiva> glen: that's basically the "handler context" ... which the handler should be able to query and access as needed (and maybe store in the session context and modify while running for example) [20:42]<gdaniels> sanjiva: yes exactly [20:42]<sanjiva> cool .. so does anyone want to dissent the agreement that handlers are stateless with the behaviour we've discussed? [20:43]<gdaniels> no objections, motion carried :) [20:43]<Srinath> :) [20:43]<Deepal> glen :) [20:43]<Chinthaka> :) [20:43]<Ajith> :D [20:43]<sanjiva> Glen's been in too many standards meetings these days ;-) [20:44]<gdaniels> heh - that'd be funnier if it wasn't true! :) [20:44]<Srinath> yap :D:D [20:44]<Ajith> ;D [20:44]<sanjiva> ok so where were u guys on phase stuff? [20:45] *** _chris_ quit FreeNode : Remote closed the connection [20:45]<Deepal> wt realy implies by before and after [20:45]<gdaniels> I think we've got the basics down, we were talking about deployment expressivity for handlers [20:45]<gdaniels> how much you can say, how hard will it be to implement and keep everything coherent, etc [20:45]<Deepal> is taht hander or pahse or both [20:45]<Deepal> sorry phase [20:46]<Deepal> handler not hander [20:46]<gdaniels> Deepal is saying that we were wondering if you can deploy "before" and "after" a given Phase, a given Handler, or both... [20:46]<sanjiva> I suggest KISS for now at least .. [20:46]<sanjiva> what's the minimal amount we need?? [20:46]<gdaniels> I agree - for the first model, we probably don't even need before and after [20:47]<sanjiva> deploy into a phase without ordering within a phase is absolutely needed I guess [20:47]<Deepal> glen : ) [20:47]<Srinath> yes I like only pahses there:) [20:47]<gdaniels> just "in this phase", "first in this phase", "last in this phase" [20:47]<sanjiva> maybe first is also useful (for security) [20:47]<gdaniels> ya [20:47]<sanjiva> "last in this phase" is prolly not needed for now but doing that if we're doing "first" should be easy .. [20:47]<sanjiva> I suggest we stop at that rather than doing "before X" and "after X" type stuff [20:47]<sanjiva> let's do those when someone has a need for it! [20:48]<gdaniels> right [20:48]<sanjiva> Deepal what do u think? [20:48]<Deepal> cool [20:48]<sanjiva> what about the phases themselves? [20:49]<sanjiva> named by URI yes? [20:49]<Srinath> and ordered at the server.xml [20:49]<Deepal> i didnt get u sir [20:49]<sanjiva> BTW I suggest we *not* parse URI strings into java.net.URI classes .. I have evidence that that's *very, very* slow. We can keep them as strings and parse into java.net.URI only if needed! [20:50]<Srinath> shall we try give exaple to phases ... [20:50]<sanjiva> Sorry Deepal - I mean hav we agreed to name phases by URIs? I think we did at the mtg but its been a while :) [20:50]<Srinath> e.g.is aythentication is a phase? [20:50]<gdaniels> sanjiva: ok to Strings from me [20:50]<gdaniels> in fact I'm not sure I see a need for URIs [20:50]<sanjiva> Srinath: what's the list of phases you have in mind for a start? [20:50]<sanjiva> glen: +1! [20:50]<gdaniels> "authentication", "dispatch", etc [20:51]<Srinath> Authentication, Encryption .. dipatch.. [20:51]<gdaniels> I use Strings in my example/toy code [20:51]<sanjiva> we can still tell users to name them via URI formatted strings .. just makes it scalable [20:51]<Srinath> one or more loggin pahses, RM [20:51] *** Essington joined #apache-axis [20:51]<sanjiva> oh I was thinking much simpler than that: "transport", "global", "service" for a start!!! [20:51]<sanjiva> That'll give axis1 level function immediately [20:51]<gdaniels> those are in my model too [20:52]<gdaniels> though simplistically for now [20:52]<FR^2> Hi Essington [20:52]<Srinath> are service/golbal..ect are pahses ? [20:52]<Essington> howdy [20:52]<sanjiva> "authentication" is a logical phase right? I mean that that could've been called "potato' and it makes no diff to the engine right?? [20:53]<sanjiva> Srinath: yes! Why not?? There's nothing 'special' about them except that the ordering is burnt into the engine .. and other phases have to fit relative to that [20:53]<gdaniels> right [20:53]<gdaniels> although! [20:53]<Srinath> yes sir but where the more specifc one fit in .. as sub phases? [20:53]<Srinath> specific ones - authentication! [20:53]<gdaniels> in my impl, a phase is associated with a Phase object... and that has specific preconditions and postconditions (optionally) [20:53]<gdaniels> so "Dispatch" == phases.DispatchPhase, which has a postcondition of making sure the service is set in the MC [20:54]<sanjiva> Glen: but how does the engine know that "Dispatch" should be run after transport and not before? [20:54]<sanjiva> We can't keep reevaluating all the pre-conds obviously [20:54]<gdaniels> that's a deployment thing [20:54]<Deepal> I thnk thats on server.xml [20:54]<gdaniels> you evaluate the precondition on entry to the phase, and the postcondition on exit [20:54]<gdaniels> once each [20:55]<Srinath> yap geln: but where the dispatch pahse fit it ? inside .. outside service/transport! [20:55]<sanjiva> That'll be like a rule-based engine for phases .. whcih woudl be cool (and very powerful) but damned slow for the general case [20:55]<gdaniels> they're not invariants :) [20:55]<gdaniels> sanjiva: I don't think it'll be slow, since many Phases won't use a specific subclass at all. Just the ones that need it. [20:56]<gdaniels> Srinath: don't think inside/outside, think before/after [20:56]<gdaniels> Dispatch is the last thing before the Service [20:56]<sanjiva> so glen: I deploy a handler for phase "Dispatch" yes? And that phase is listed in the something.config to tell the server where that goes relative to the rest of the phases?? [20:56]<gdaniels> right, although that one might be unchangeable since it's an engine thing [20:57]<gdaniels> (you can deploy stuff before/after it, but not take it out) [20:57]<Srinath> glen:that mean the service/trasport/gobal do not cover evrythig [20:57]<gdaniels> correct [20:58]<gdaniels> incoming msg goes transport, global, dispatch, service, I think [20:58]<sanjiva> let's be precise: for now let's say there's a <phaseOrder> element in engine.config say: <phaseOrder><phase name="uri1"/> ... </phase name="urin"/></phaseOrder> [20:59]<sanjiva> and we have special uris for transport/global/service which are constants [20:59]<Srinath> cool .. amy be we need some conditions like user can not put thing before global phase ect [20:59]<gdaniels> outgoing msg goes service, global, transport for now [20:59]<gdaniels> Srinath: yes [20:59]<sanjiva> and the user cannot change that order .. i.e., the default phaseOrder for input is: transport, global, service and the reverse for output [21:00]<Srinath> yes .. user can put after or before service as appropriatly [21:01]<sanjiva> right, I guess we have to be careful to maek sure the built-in phases are as "small" or "narrow" as possible ..otherwise we're going to need hiearchical phases to enable maximum flexibility which would be very bad [21:01]<gdaniels> sanjiva: +1 [21:02]<gdaniels> ok, it's 7AM here, and I need to hop in the shower and get ready to head south [21:03]<gdaniels> anything else to discuss, or shall we adjourn the official part of the chat for this week? [21:03]<sanjiva> Ajith: I just sent a reply to your OM note to the axis-dev list [21:03]<sanjiva> Glen: +1 .. see u in a few hrs! [21:03]<Srinath> we got to go too .. I think [21:03]<sanjiva> (let's try to spend some whiteboard time today or tomorrow on axis2 ..) [21:04]<sanjiva> good nite guys! [21:04]<Chinthaka> wait, [21:04]<gdaniels> sanjiva: +1! [21:04]<sanjiva> waiting :) [21:04]<Chinthaka> when is the next week chat [21:04]<Chinthaka> I mean the time [21:04]<gdaniels> next week :) [21:04]<gdaniels> oh :) [21:04]<Chinthaka> in the morning ? :D [21:04]<gdaniels> are we switching to the other time? [21:04]<gdaniels> 10PM EST, 9AM Sri Lanka? [21:04]<Chinthaka> yeah [21:05]<Chinthaka> if u have no probs in that [21:05]<sanjiva> oh yeah .. i can't do 9am eastern :-( ... have to be at ICSOC (www.icsoc.org) introducing adam bosworth .. [21:05]<sanjiva> 10pm eastern may work for me! [21:05]<gdaniels> cool-o [21:05]<sanjiva> ok! glen will u post the log pls? [21:05]<sanjiva> (no alek today) [21:05]<gdaniels> I'll send reminder mail to axis-dev (and get that cron job going) [21:05]<Ajith> I have the logs too [21:05]<gdaniels> sanjiva: ya [21:05]<gdaniels> I got it this wk, Ajith [21:05]<Ajith> I can post them if you guys want to [21:05]<Ajith> ok cool [21:05]<Chinthaka> so see u all next week 10PM EST, 9AM Sri Lanka [21:06]<gdaniels> yup! [21:06]<sanjiva> ok bye all! [21:06]<gdaniels> bye for now [21:06]<Chinthaka> byee all [21:06]<Deepal> bye all [21:06] *** Chinthaka quit FreeNode : [21:06]<Srinath> bye all [21:06] *** gdaniels quit FreeNode : [21:06] *** Srinath quit FreeNode : "Client Exiting"