Chat log for 10th Novemeber 2004

[Ajith Ranabahu <aj...@gmail.com>]

Here is the chat log :)

[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"

[END OF LOG] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-- 
Ajith Ranabahu

please use [Axis2] prefix [Re: Chat log for 10th Novemeber 2004

[Aleksander Slominski <as...@cs.indiana.edu>]

Glen Daniels wrote:

>Just an FYI for everyone - please remember to use [Axis2...] in your subject
>lines for Axis2-related stuff, so that procmail rules and the like can
>accurately find it.  Thx!
>  
>
+1 this is really important for  "filter enabled" people that need to 
handle lot of emails....

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay

RE: Chat log for 10th Novemeber 2004

[Glen Daniels <gl...@thoughtcraft.com>]

Hi Ajith, all:

Thanks for posting that - I sent the log last Wednesday, but apparently my
outgoing mail server had some problems. :(  Sorry for not catching that
earlier and resending.

Just an FYI for everyone - please remember to use [Axis2...] in your subject
lines for Axis2-related stuff, so that procmail rules and the like can
accurately find it.  Thx!

--Glen 

> -----Original Message-----
> From: Ajith Ranabahu [mailto:ajith.ranabahu@gmail.com] 
> Sent: Sunday, November 14, 2004 10:02 PM
> To: Axis developer list
> Subject: Chat log for 10th Novemeber 2004
> 
> Here is the chat log :)
> 
> [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"
> 
> [END OF LOG] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> -- 
> Ajith Ranabahu
> 
>