axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject [Axis2] IRC log 2004-09-01
Date Thu, 02 Sep 2004 13:34:05 GMT

Session Start: Wed Sep 01 08:59:51 2004
Session Ident: #apache-axis
[08:59] * Now talking in #apache-axis
[08:59] * Topic is 'Apache Axis - soap compliant web service api'
[08:59] * Set by FR^2 on Wed Mar 24 09:54:11
[09:00] * as10m has joined #apache-axis
[09:01] <gdaniels> Good morning / evening everyone
[09:01] <srinathAndDeepal> good morning
[09:01] <srinathAndDeepal> :)
[09:01] <Jaliya> Good evening
[09:01] * gdaniels changes topic to 'Axis2 Weekly Chat'
[09:02] <as10m> good early morning
[09:02] <gdaniels> Hope everyone had a great week...
[09:02] <srinathAndDeepal> Any body see the Archi doc in wiki :)
[09:02] <gdaniels> Did you post one?
[09:03] <srinathAndDeepal>
[09:03] <gdaniels> sweeeeeeeet
[09:03] <srinathAndDeepal> yesterday
[09:03] <srinathAndDeepal> try to devide modules and what belongs to
each module
[09:04] <gdaniels> nicely done
[09:04] <srinathAndDeepal> there is a wiki for each module
[09:04] <Jaliya> Yes it is good
[09:04] <srinathAndDeepal> link at the bottem
[09:04] <srinathAndDeepal> for each module ..
[09:04] <srinathAndDeepal> need to shape things up .. that is start
[09:04] <gdaniels> says
"distroty()" :)
[09:05] <gdaniels> This looks great, guys
[09:05] <Jaliya> oops
[09:05] <gdaniels> Thanks for setting it up
[09:05] <srinathAndDeepal> oops ..
[09:05] <Jaliya> Glen did you start coding
[09:05] <gdaniels> yup
[09:06] <srinathAndDeepal> what ever already at the axis handler .. I
think t is clean up
[09:06] <gdaniels> I don't have anything solid yet, but will check in
what I've got as soon as we've got a place to put it.
[09:06] <Jaliya> Actually how can we finalize the interfaces for modules
[09:06] <Jaliya> By way of code interfaces or diagrams
[09:06] <gdaniels> We finalize the interfaces, I think, by making
[09:06] <srinathAndDeepal> BTW these ppl going kill me since I start
coding :(
[09:06] <srinathAndDeepal> SL ppl
[09:06] <gdaniels> oh?  Why's that, Srinath?
[09:06] <gdaniels> (or Deepal :))
[09:07] <srinathAndDeepal> Srinath :)
[09:07] <srinathAndDeepal> they fear it all over in two weeks .. 
[09:07] <gdaniels> Jaliya: diagrams or interfaces, either way.  Code is
easier to transmit/view
[09:07] <srinathAndDeepal> yap I agree 100%
[09:07] <Jaliya> Ok, accepted
[09:08] <Ajith> oh you guys started talking
[09:08] <Ajith> hi all
[09:08] <Ajith> well to tell the truth i am on jaliyas side
[09:08] <gdaniels> This is what we did with the original Axis too.
Several people posted similar frameworks, then we picked one (Doug
Davis', IIRC) and just started building on that one.
[09:08] <srinathAndDeepal> Ajith good morning ..... :D
[09:08] <gdaniels> Hi Ajith
[09:09] <gdaniels> Ajith: on Jaliya's side about what?
[09:09] <Ajith> i also think we need some solid diagrams to start with
[09:09] <srinathAndDeepal> I have a bit of interfaces writen here as
well ..
[09:09] <Ajith> oh
[09:10] <srinathAndDeepal> see they going to kill me :D for writing code
[09:10] <farhaan> yeah we got a few trail blazers here
[09:10] <gdaniels> I agree we need diagrams and clearly we also need
code. :)  But I don't think it much matters which comes first at this
[09:10] <Ajith> what i feel is without these pictures we will lose the
big picture
[09:10] <srinathAndDeepal> with you glean :) :) :)
[09:10] <srinathAndDeepal> sorry glen
[09:10] <gdaniels> s'ok :)
[09:11] <gdaniels> I gave a report on the meeting yesterday to some
folks at Sonic, they were very psyched.
[09:11] <Ajith> cool
[09:11] <Jaliya> cool
[09:11] <gdaniels> I'm hoping we can devote some resources to helping
[09:11] <Jaliya> that is great
[09:11] <Ajith> great
[09:11] <srinathAndDeepal> oh :) great
[09:12] <gdaniels> So we need dims to set up that SVN tree sometime soon
so we can start dropping breadcrumbs for each other...
[09:12] <Ajith> yep
[09:12] <srinathAndDeepal> yes
[09:13] <Jaliya> Yes, So until that we can come up with different
proposals right?
[09:13] <Jaliya> I mean implementations
[09:13] <srinathAndDeepal> I think OM is bit independent 
[09:13] <gdaniels> Yes, but the sooner we get the ability to share them
via SVN the better.  Until then we can zip them and mail them to the
list, I guess.
[09:13] <Ajith> great
[09:13] <Jaliya> Yes, that we can do
[09:14] <srinathAndDeepal> ppl can start working on it / OM
[09:14] <gdaniels> Srinath: Agreed, although the OM/DataBinding pieces
are deeply bound together.
[09:14] <gdaniels> Well, sort of deeply. :)  The OM get/setObject APIs
need access to the serialization/deserialization contexts, which need
good APIs.
[09:14] <Ajith> I guess if we can attach even a simple document (other
than code) with our code it will be better
[09:14] <srinathAndDeepal> yes but we define OM and (it is DOM and pull)
and do data binding on top
[09:15] <srinathAndDeepal> alek did u get a chance to hav a look at the
OM things
[09:15] <gdaniels> Srinath - yes, but it depends on how you think about
it.  We talked about omElement.getObjectValue() at the F2F, for
[09:15] <srinathAndDeepal> Ajith was one in to it
[09:16] <srinathAndDeepal> yes I accept
[09:16] <srinathAndDeepal> we can put that in OM
[09:16] <Ajith> I guess the best thing is to define the external
interface to OM and everybody relying on it to write their own
[09:16] <srinathAndDeepal> yes ..
[09:16] <as10m> yes i looked
[09:16] <as10m> defining interfaces would be really important
[09:16] <Ajith> then we can pick the best "framework"
[09:17] <srinathAndDeepal> yes ..
[09:17] <Jaliya> yes
[09:17] <gdaniels> Yes, but to make the OM object integration work, OM's
public interface needs some kind of
setSerializationContext()/setDeserializationContext() API...
[09:17] <as10m> and would help to keep modules separation clear
[09:17] <gdaniels> +1 Alek
[09:17] <Ajith> yep
[09:17] <Jaliya> +1 from me
[09:17] <as10m> shold nto (De)Serialization context be just sibpart of
[09:18] <gdaniels> I don't think so, Alek, although it may live in there
[09:18] <srinathAndDeepal> +1 axis and OM seperate as much as posisble
[09:18] <Ajith> I agree to srinath
[09:18] <Jaliya> Can we start working with the engine without
considering about OM
[09:18] <gdaniels> The (De)SerializationContext interfaces are pretty
simple, I think.
[09:18] <Jaliya> I mean in the intial stage
[09:18] <srinathAndDeepal> shall we hav OM code + OM and Axis code
[09:18] <gdaniels> Jaliya: Definitely, though we need a placeholder
(that's what I did)
[09:19] <Jaliya> yep, got it
[09:19] <srinathAndDeepal> clean seperate OM and Utils for axis
[09:19] <gdaniels> Message needs to contain something, so I made a
mostly-empty "OmElement"
[09:19] <Ajith> aha
[09:19] <as10m> i think if there are good OM interfaces it will help to
improve implementation without breaking other places
[09:19] <gdaniels> OM is definitely useful outside the context of Axis
[09:19] <Ajith> yep
[09:19] <srinathAndDeepal> yes
[09:19] <Ajith> that is what also felt
[09:20] <Ajith> Om would be something like DOM or JDOM that ppl will use
[09:20] <srinathAndDeepal> OM next generatio replacment for DOM :)
[09:20] <Ajith> which u can just plug in
[09:20] <gdaniels> I wonder how much DOM we're really going to need to
directly implement...
[09:21] <gdaniels> Security was brought up as the main use-case, and I
haven't looked at that code
[09:21] <srinathAndDeepal> yes .. it is a subset 
[09:21] <Jaliya> I think we need most of it
[09:21] <srinathAndDeepal> I think Dims hav a idea
[09:22] <as10m> AFAIK security libs uses Xalan for XPath expressions so
fairly complete support may be required (except maybe for comments, PIs)
[09:22] <gdaniels> yeah, that's what I was worried about. :)
[09:22] <farhaan> From what I know about security we practicaly have to
read the entire body and this means implementing the whole of DOM
[09:23] <srinathAndDeepal> yes it may be nearly DOM 
[09:23] <gdaniels> well, let's see how a first pass goes, and if we feel
the DOM is making us too heavyweight/inefficient, we can build a really
minimal OM API (not caring about DOM at all) and then a DOM shim on top
[09:24] <srinathAndDeepal> +1 for glen
[09:24] <gdaniels> We should be able to do DOM pretty efficiently
though, I'd hope....
[09:24] <Ajith> yeah that is right
[09:24] <Jaliya> Yes that is it
[09:24] <Jaliya> At this moment we have to go with minimum dom I think
[09:25] <Ajith> yep
[09:25] <Ajith> the minimum requirement to make a DOM like structure
[09:25] <as10m> yes - DOM can be pretty heavywight so that would be good
to allow using OM without DOM when no DOM suopported is required ...
[09:26] <srinathAndDeepal> we forget the suport for SAAJ for time been I
[09:26] <gdaniels> Well, maybe.
[09:26] <gdaniels> We certainly need something like it.
[09:27] <gdaniels> i.e. getMustUnderstand() on headers, etc
[09:27] <Jaliya> ?
[09:27] <srinathAndDeepal> yes we agreed to forget Java spec for Mi at
[09:27] * sanjiva has joined #apache-axis
[09:27] <sanjiva> hi Guys! Sorry to be late .. I forgot the time :-(
[09:27] <as10m> i think in general it would be good to attach
annotations to any XML element in OM ...
[09:28] <srinathAndDeepal> :)
[09:28] <gdaniels> Jaliya:
omEnvelope.getHeaderByQName(qname).getMustUnderstand().... etc
[09:28] <as10m> hello Sanjiva
[09:28] <gdaniels> hi Sanjiva
[09:28] <Jaliya> Yes, got it
[09:28] <gdaniels> Alek: i.e. omElement.setProperty(name, object)?
[09:29] <sanjiva> On annotations - Alek have u seen the working draft
the wsdl group published for annotating a schema with mime info?
[09:29] <gdaniels> Sanjiva: although that's more about the schema model
than OM....
[09:29] <as10m> Sanjiva: no i did not read it
[09:30] <sanjiva> right but shouldn't that basically find its way into
the element? and that's pretty much what enables MTOM optimzation right?
[09:30] <as10m> Glen: somethign liek that is minimum i think, better
would be to allow to attach interface/impl to element node soo you could
add DOM (SAAJ) when needed
[09:30] <gdaniels> Yup
[09:30] <srinathAndDeepal> yes implement DOM on top
[09:30] <gdaniels> Alek: You mean like using dynamic proxies?
[09:31] <sanjiva> Isn't of a setProperty method, how about a single
"userData" kind of thing that one can attach at any node in the OM?
[09:31] <gdaniels> sanjiva: isn't that the same thing?
[09:31] <as10m> AFAIU: for MTOM optimizations i think you need to store
a pointer to binary data deserialized and be able to build infoset
equivalent on deman (BASE64)
[09:31] <sanjiva> That allows the OM to be Axis and SOAP independent,
which we wanted I believe
[09:31] <gdaniels> Alek: yes, definitely.
[09:31] <sanjiva> I guess setProperty is the same .. but setProperty
gets confusing with WSDL properties ..
[09:32] <gdaniels> Not to mention storing Java object equivalents
[09:32] <as10m> i think DOM3 already has this kind of APIs for storing
properties with nodes
[09:32] <sanjiva> I imagine we'll need exactly the same for the WSDL
model if we're going to run messages using the model as we discussed as
a tentative possibility
[09:32] <as10m> Glen: i think it would be great if OM allowed to store
both XML and Java content 
[09:32] <gdaniels> sanjiva: this is a runtime XML model, not a WSDL
model, though.  I don't think it's confusing - but in any case, it's
just a name, we agree on the functionality
[09:32] <sanjiva> yes, +1 on function
[09:32] <gdaniels> Alek: +1, but that's why it needs a plug point for
the ser/deser system
[09:33] <as10m> Glen: do you want to store deserializers in OM?
[09:33] <Ajith> I dont think its a good idea
[09:33] <gdaniels> Alek: No.
[09:33] <as10m> +1 on function
[09:33] <srinathAndDeepal> no I belvie
[09:34] <sanjiva> Alek: not necessarily store them, but be able to
associate one at a given point to be able to ask that deser to give Java
for that element on down.
[09:34] <as10m> Glen: i think would need to see the code you are writing
[09:34] <gdaniels> I want to store a DeserializationContext in OM, which
gets at deserializers in whatever implementation-dependent way it wants
[09:34] <gdaniels> simple example:
[09:34] <gdaniels> interface DeserializationContext {
[09:34] <as10m> OK so this is DeserContext: associate deserialzier with
soem type of OM node 
[09:35] <gdaniels>   Object deserialize(OmElement om, Context ctx);
[09:35] <gdaniels> }
[09:35] <gdaniels> interface OmElement {
[09:35] <gdaniels>   void
setDeserializationContext(DeserializationContext ctx);
[09:35] <gdaniels> }
[09:35] <gdaniels> class OmElementImpl ... {
[09:35] <gdaniels>   public Object getAsObject() {
[09:35] <gdaniels>     this.deserContext.deserialize(this, ...)
[09:35] <sanjiva> Glen, that's redundant .. should be
OmElement::setDeserializationContext (Context ctx) ..
[09:35] <gdaniels> }
[09:36] <srinathAndDeepal> shall we make Deserialization ontext work on
top of OM .. not inside
[09:36] <gdaniels> By "Context ctx" I actually meant not a deser
context, but any other context which might be needed to deser THIS
particular element
[09:36] <gdaniels> This is obviously off the top of my head, though -
not thought through
[09:36] <as10m> Glen: so each time getAsObject is called deserialziation
happens? seems inefficient? how many times do you plan to do
[09:36] <Ajith> I agree to Srinath
[09:36] <gdaniels> No, it'd cache. :P
[09:37] <sanjiva> Right, like a mapping table of previously deser'ed
stuff for example. I got that .. but since you're goiing to a given
element, it should be possible to ask that object to deserialize itself
[09:37] <gdaniels> I was just tossing an example API.  Sheesh, tough
crowd. :)
[09:37] <srinathAndDeepal> see Deserializer
[09:37] <sanjiva> ;-)
[09:37] <srinathAndDeepal> ;-)
[09:38] <as10m>
[09:38] <as10m> :)
[09:38] <srinathAndDeepal> yes .. that link u se on top
[09:38] <gdaniels> Srinath, the thing about layering is that I think the
same APIs are useful for MTOM optimization and ser/deser...
[09:38] <gdaniels> MTOM stuff probably needs to be in OM proper, so
therefore why not make those same APIs able to access a ser/deser system
[09:39] <gdaniels> All we do is define the context APIs though and
that's the abstraction boundary
[09:39] <as10m> Glen: i see the need
[09:39] <gdaniels> the modules are still separate
[09:39] <sanjiva> how about OmElement::deserializeYourself (context) and
OmElement::setDeserializer (deser), where deser is something which
implements interface Deserializer { Object deserialize (OmElement node,
Context context); }
[09:39] <srinathAndDeepal> I do not know MTOM stuff by heart
[09:39] <as10m> Glen: what i think is needed is to be able to access XML
event stream from OM element
[09:39] <sanjiva> Gotta memorize the MTOM spec dude ;-))
[09:39] <gdaniels> sanjiva: because setDeserializer() implies you've
already picked a deserializer, which I think is easier to leave up to a
[09:40] <sanjiva> (And explain it to me after you do because I haven't
read it!!!)
[09:40] <gdaniels> Alek: Yes, we've got that in the plan too.
[09:40] <srinathAndDeepal> yes .. will do home work :)
[09:40] <as10m> interface OmElement { XmlPullParser getEventStream(); }
[09:40] <gdaniels> Which implies serialization if you've done
[09:41] <sanjiva> Glen: Do you really see deserializers being so
dynamically set? To me the choice of Castor or JAXB or whatever is a
very "static" decision made at system config kind of time ..
[09:41] <srinathAndDeepal> yes .. I thought deserialzer need a puu API
[09:41] <srinathAndDeepal> pull
[09:41] <gdaniels> It's not the choice of Castor vs. JAXB, it's about
the context of a particular element vis a vis its schema/typeMapping
[09:41] <gdaniels> xsi:type, WSDL, etc
[09:42] <gdaniels> Castor vs. JAXB is about which implementation of
DeserializationContext you use, I think.
[09:42] <as10m> Sanjiva: we should consider also support for XML
piplines such as transforming message with multiple tools: XSLT,
XmlBeans, castor, BeanDeser - possibly all of them when different SOAP
headers are processed
[09:42] <sanjiva> ok undestood - that's what I put in the context
argument to teh deserialize method .. so I think we're talking about
nearly the same thing - probably need code to see the details.
[09:42] <as10m> Glen: i agree about choixe
[09:42] <srinathAndDeepal> yes 
[09:42] <gdaniels> sanjiva: +1
[09:42] <srinathAndDeepal> have the deserializer work on pull apI ONLY
[09:43] <as10m> sanjiva: +1 we need to look on code
[09:43] <gdaniels> Srinath: It actually doesn't really matter...
[09:43] <Ajith> glen is right in this
[09:43] <gdaniels> If it uses the pull API, it'll be faster when
deserializing on a stream
[09:43] <gdaniels> (i.e. a non-cached-in-OM stream)
[09:43] <as10m> srinath: pull API can work on top of OM so it should not
matter if you access only OM or pull event stream
[09:43] <srinathAndDeepal> yes
[09:43] <Ajith> we shouldnt put everything relying on the pull parser
[09:43] <gdaniels> If it uses OM object methods, that'll just force
building the OM, which will be slower but still work.
[09:44] <as10m> glen: +1
[09:44] <sanjiva> Did we decide whether to have OM expose the pull API
directly or you have to ask OM for a pull parser (with caching or not)?
[09:44] <srinathAndDeepal> but even cached case we can simulate pull api
[09:44] <Ajith> do we?
[09:44] <gdaniels> Srinath: absolutely. 
[09:44] <srinathAndDeepal> hav deserialser work only on pull
[09:44] <gdaniels> Sanjiva: I don't think we decided.
[09:44] <gdaniels> Srinath: I don't see why you limit that.
[09:44] <Ajith> so are we bound to pull only?
[09:44] <sanjiva> So, PullParserInterface OMElement.getPullParser
(boolean cacheIntoOmOrNot)?
[09:44] <gdaniels> Think about the deserializer - what's it going to
[09:45] <gdaniels> If it gets an omElement, it's got BOTH the OM *and*
access to a pull stream.
[09:45] <gdaniels> If it gets just a pull stream, it's limited to pull.
[09:45] <gdaniels> Why limit it?
[09:45] * as10m has quit IRC (Read error: 104 (Connection reset by
[09:45] <gdaniels> sanjiva: I think we leave that as an open issue for
now until we do some prototyping.
[09:45] <sanjiva> Yeah and if we want to support SOAPEnc (which we've
agreed to do) then you can't do only with pull .. u need the old context
and future stuff.
[09:45] <srinathAndDeepal> yes deserialier pull only make the thing
[09:45] <sanjiva> Glen: ok.
[09:45] <srinathAndDeepal> I fee so
[09:46] <gdaniels> Srinath: I don't think giving it OM makes it any less
simple, if we do our jobs well! :)
[09:46] <sanjiva> "I fee so"???? 
[09:46] <Ajith> ok agreed for the time being
[09:46] <gdaniels> He's saying he'll charge us a fee if we make that
decision, Sanjiva. :)
[09:46] <srinathAndDeepal> opps .. does what come there
[09:46] * as10m has joined #apache-axis
[09:46] <sanjiva> ah ;-)
[09:46] <gdaniels> s/fee/feel/
[09:46] <srinathAndDeepal> :)
[09:47] <Ajith> But I strongly think we should be flexible enough to use
another parsing method also
[09:47] <sanjiva> Glen, I missed the first part .. did u get to write
code on the plane?
[09:47] <gdaniels> I did, but not as much as I'd hoped.
[09:47] <sanjiva> (Alek's coming back)
[09:47] <sanjiva> (IRC client died apparnetly
[09:47] <sanjiva> )
[09:47] <gdaniels> I'll check in what I've got as a scratchpad thing
once we've got SVN up
[09:48] <Ajith> BTW dims is not in?
[09:48] <sanjiva> ok - Dims seems to be offline mostly .. it may take
some time. Do you want to put it in axis/contrib/axis2 or something in
the meantime?
[09:48] <Jaliya> yes, it will be good
[09:48] <srinathAndDeepal> +1
[09:48] <sanjiva> Dims is on vacation in India ... he did reply to stuff
on lists yesterday nite so maybe he's catching up at nite
[09:48] <gdaniels> Sure, I can do that.  It'll probably be EOW, though,
since I'm buried in catchup stuff
[09:48] <Ajith> sooner the better i sould say
[09:48] <gdaniels> yep, sooner good
[09:48] <sanjiva> Glen: that's fine .. if Dims hasn't got it up by then
then pls drop it into axis/contrib/axis2
[09:49] <gdaniels> All I did was a swipe at the handler flow / engine
[09:49] <eXtreme> hi guys
[09:49] <gdaniels> Uses the responder/sender thingy and splits the
[09:49] <gdaniels> doesn't yet do the WSDL object model or the
operation-specific handlers, but I like it anyway. :)
[09:50] <gdaniels> It simulates HTTP and doesn't use a real servlet
either.  Just a strawman.
[09:50] <eXtreme> sorry I'm bit late :(
[09:50] <sanjiva> Srinath you said you were prototying stuff too right -
so put that in too ASAP?
[09:50] <as10m> Glen: about performance
[09:50] <as10m> Glen: we should not asume pwrformance is good or bad of
OM until it is fine tuned
[09:50] <srinathAndDeepal> how about contrib/axis2/glen
[09:50] <sanjiva> I will work with Priyanga and Alek to work out the
pull parser interface on top of StAX and put that in ..
[09:50] <srinathAndDeepal> mine axis2/srinath
[09:50] <sanjiva> +1 Srinath to contrib/axis2/gdaniels etc.
[09:50] <Ajith> ok
[09:50] * eXtreme is now known as Chinthaka
[09:50] <srinathAndDeepal> opps extreme ????
[09:50] <Chinthaka> :)
[09:51] <Chinthaka> forget it, continue this :(
[09:51] <gdaniels> Welcome, Chinthaka :)
[09:51] <gdaniels> I've got a hard stop at 10, unfortunately. :(
[09:51] <sanjiva> Hi Chinthaka
[09:51] <Jaliya> dims coming
[09:52] * dims has joined #apache-axis
[09:52] <dims> hey all
[09:52] <gdaniels> Hi dims :)
[09:52] <Jaliya> Hi dims
[09:52] <srinathAndDeepal> Hi Dims:)
[09:52] <sanjiva> Hey Dims!
[09:52] <Ajith> hi
[09:52] <dims> sorry for the delay
[09:52] <Chinthaka> hi dims
[09:52] <Ajith> we missed you :D
[09:52] <sanjiva> Better late that never .. and especially since we gave
you work ;-)
[09:52] <gdaniels> dims : what do you think about setting up the SVN
framework soonish?  Possible for you while there?
[09:53] <srinathAndDeepal> ppl going to commit contib/axis2/xxx
[09:53] <dims> Will do first thing tomorrow.
[09:53] <dims> ok?
[09:53] <gdaniels> Whoa, that's fast!
[09:53] <srinathAndDeepal> :)
[09:53] <Jaliya> o
[09:53] <Jaliya> ok
[09:53] <Chinthaka> cool
[09:53] <Ajith> great
[09:53] <dims> hopefully
[09:53] <Jaliya> Ah
[09:53] <srinathAndDeepal> :(
[09:53] <gdaniels> Sure - and anyone who knows pointers to SVN usage
sites, plugins, etc, please put links on a WIKI page?
[09:53] <as10m> :)
[09:54] <sanjiva> Yes that will be useful!
[09:54] <Chinthaka> sure
[09:54] <Ajith> sure we will do that
[09:54] <Chinthaka> I got some SVN usage stuff
[09:54] <dims> see
[09:55] <gdaniels> So can we talk about short-term goals for the coming
[09:55] <gdaniels> 1) dims to set up SVN
[09:55] <Chinthaka> yeah, thats good
[09:55] <srinathAndDeepal> does it accept cvs commands
[09:55] <gdaniels> 2) Glen and Srinath to check in strawman code in
[09:56] <sanjiva> s&d: no - you have to use an SVN command
[09:56] <sanjiva> and BTW SVN works over HTTP .. may even work with
proxies and such I think!
[09:56] <gdaniels> 3) Everyone to review/contribute to Wiki architecture
[09:56] <srinathAndDeepal> yes I read part on cvs
[09:56] <dims> We are doing that already
[09:56] <dims> :)
[09:56] <gdaniels> 4) axis-dev discussion to figure out agenda for next
week's chat
[09:57] <Jaliya> Glen as you said, is the sender uses a provider
[09:57] <Ajith> ?
[09:57] <gdaniels> Jalyiya: ?
[09:57] <gdaniels> s/Jalyiya/Jaliya/
[09:57] <sanjiva> Did we decide to use org.apache.axis.* for code? That
means to use axis1 code we'll have to copy it to the new dir .. which is
not criminal but can be a maintenance headache.
[09:58] <gdaniels> sanjiva: Yes, I think we did.
[09:58] <srinathAndDeepal> yes
[09:58] <Jaliya> I mean the in our discussion we replace the provider
using operation, right?
[09:58] <sanjiva> ok that' sfine
[09:59] <Ajith> with the tools we use we can refactor easily
[09:59] <gdaniels> Jaliya: The work of calling the back-end "service
method" happens inside the Operation object, but we didn't get all the
way to figuring out exactly how that works, I think.
[09:59] <srinathAndDeepal> Ajith yes bur maintance headache
[10:00] <gdaniels> i.e. there's probably still a Provider-like class,
but it attaches to the Operation
[10:00] <Jaliya> Yes, that is it. We need to figure that out
[10:00] <sanjiva> +1 to Operation having some helper .. and having to
see code to figure that out. 
[10:01] <srinathAndDeepal> yes .. we need some provider like calss
[10:01] <gdaniels> yup
[10:01] <Jaliya> Yes,that is requried
[10:01] <gdaniels> OK, I need to go get ready for another meeting....
[10:01] <gdaniels> are other people logging?
[10:01] <srinathAndDeepal> thanks Glen
[10:02] <gdaniels> I can leave my IRC window up and then post the
minutes to the list later today....
[10:02] <sanjiva> OK .. sounds good - I have to go too though but I'll
keep the window open. 
[10:02] <dims> jaliya: did that SOAPService constructor work for u?
[10:02] <gdaniels> OK, bye all, and enjoy the rest of the conversation!
I'll have more time next week...
[10:02] * gdaniels is now known as glen-away
[10:02] <sanjiva> L8r Glen 
[10:02] <srinathAndDeepal> bye gen
[10:02] <Jaliya> Dims: Yes, but only one handler
[10:02] <Ajith> bye
[10:02] <srinathAndDeepal> mean Glen
[10:03] <Jaliya> Dims: I need two
[10:03] <dims> folks: Please post your Yahoo IM handle to Wiki
[10:03] <Jaliya> Bye Glen and Sanjiva
[10:03] <Ajith> yep that will be very helpful
[10:03] <sanjiva> Alek: The WSDL media types WD is
[10:04] <Chinthaka> hey guys I got a eclispe plugin for SVN 
[10:04] <dims> Jaliya: create a SimpleChain add your handlers and then
use that as a parameter for SOAPService
[10:04] <srinathAndDeepal> giv us link
[10:04] <Chinthaka> check this out in
[10:05] <Chinthaka> this needs Eclipse 3.0
[10:05] <Jaliya> Ah
[10:05] <srinathAndDeepal> :(
[10:05] <Jaliya> Dims: I use ChainImpl
[10:05] <sanjiva> Just added my yahoo ID next to my photo
[10:05] <Jaliya> Dims: I will use SimpleChain and see
[10:06] <srinathAndDeepal> sir u supposed to add it to IM
[10:06] <dims> Jaliya: SimpleChain should work
[10:06] <dims> srinathAndDeepal: you can do the honors :)
[10:07] <Jaliya> Dims: Sure I will let you the results
[10:07] <dims> Alek: Can we use your Infoset API as the starting point
for the AXIOM thingy?
[10:07] <sanjiva> S&D: What do u mean add to IM??? Add to Wiki so
everyone can find each others' right??
[10:07] <dims> section 1.11.3 i think
[10:07] <srinathAndDeepal> there is a IM section
[10:07] <srinathAndDeepal> :)
[10:07] <dims> section 1.11.3 i think
[10:07] <sanjiva> Dims, I asked him that already and he pointed me to
rules for revolutionaries .. ;-)
[10:07] <sanjiva> S&D: Ah i c ... sorry :-(
[10:07] <dims> Is that a yes or a no? :)
[10:08] <srinathAndDeepal> :)
[10:08] <sanjiva> I told him no need to revolutionaize yet because we're
at the beginning! I didn't hear back .. (it was late nite on AIM for
[10:08] <sanjiva> Alek???
[10:08] <Ajith> for Intellij fans check this out
[10:08] <Ajith> it is a SVN plugin for the intellijIDEA IDE
[10:09] <srinathAndDeepal> ajith pls send us a licence 
[10:09] <Ajith> ?
[10:09] <Ajith> you mean for Intellij
[10:09] <srinathAndDeepal> for intelij :D
[10:09] <Ajith> I'll see
[10:10] <sanjiva> What?? Use eclipse! ;-)
[10:10] <Ajith> :D
[10:10] <Jaliya> we have a plugin
[10:10] <srinathAndDeepal> yes  eclipse
[10:10] <Ajith> ok I give up
[10:10] <sanjiva> (or stick with emacs and remain in the 20th century
like me ;-))
[10:10] <dims> Hey: If you want to use intellij then let me know :)
[10:10] <Ajith> eclipse
[10:10] <srinathAndDeepal> need a find one to 2.3
[10:10] <Jaliya>
[10:11] <Jaliya> for eclipse
[10:11] <dims> we may be able to round up some licenses for intellij
[10:11] <Jaliya> that link has a plugin
[10:11] <Chinthaka> dims : that seems interesting
[10:11] <Ajith> COOL
[10:12] <srinathAndDeepal> cool
[10:12] <Jaliya> cool
[10:12] <srinathAndDeepal> i am happy with eclpise as well BTW
[10:12] <Ajith> guess it is personal opinion
[10:13] <srinathAndDeepal> sure :) :)
[10:13] <Ajith> but I find intellij really quick and helpful
[10:13] <srinathAndDeepal> making ppl angry
[10:13] <dims> send me email individually :)
[10:13] <srinathAndDeepal> seems I am sucsessful
[10:13] <dims> i know :)
[10:13] * Essington has joined #apache-axis
[10:14] <dims> hey Jason
[10:14] <dims> see the crowd today :)
[10:15] <srinathAndDeepal> anything more on Axis 2.0?
[10:15] <srinathAndDeepal> we like to run away :)
[10:16] <Ajith> BTW axis 2 OM diagrams are in the wiki
[10:16] <Ajith>
[10:16] <dims> Ashu added
[10:16] <srinathAndDeepal> shall we merge it to archi
[10:16] <dims> your call
[10:16] <dims> am ok
[10:17] <Chinthaka> I will write a small description on OM later
[10:17] <srinathAndDeepal> Dims shall we merge the two docs
[10:18] <dims> sure
[10:18] <srinathAndDeepal> will try it .. :)
[10:18] <srinathAndDeepal> then all shall we wind up ..
[10:18] <srinathAndDeepal> actuall t not we .
[10:18] <srinathAndDeepal> shall I ;)
[10:19] <srinathAndDeepal> bye
[10:19] <sanjiva> bye s&d!
[10:19] <Jaliya> When are we meeting next?
[10:19] <sanjiva> Same time, same place, next week
[10:19] <Jaliya> cool
[10:19] <srinathAndDeepal> :)
[10:20] <Ajith> so it is 7.30 pm SLST is it?
[10:20] <srinathAndDeepal> 7.00 
[10:20] <srinathAndDeepal> bye
[10:20] <sanjiva> no - 7pm SLST
[10:20] <Ajith> ok
[10:20] <Chinthaka> hmm, one hour early :)
[10:20] <Chinthaka> thats cool
[10:21] <dims> bye all
[10:21] <Ajith> byeee
[10:21] <Essington> wow, busy place :-)
[10:21] <Jaliya> Bye dims
[10:22] <Chinthaka> byee all
[10:22] <Jaliya> Bye all
[10:22] * as10m has quit IRC (Read error: 110 (Connection timed out))
[10:22] <Essington> heh, Jason shows up and every one heads for the
[10:23] * as10m has joined #apache-axis
[10:23] <sanjiva> Hi Jason - I don't think I've met you before .. are
you going to work on axis2? Very cool!
[10:23] <sanjiva> (which company are you from BTW?)
[10:23] <Essington> Green River Computing
[10:24] <dims> FYI, Jason has done a lot of good work with
[10:24] <dims> He's a power user :)
[10:24] <Essington> sanjiva: I am more familiar with wss4j and
addressing than axis proper 
[10:24] <dims> FYI - create the JIRA issue for SVN -
[10:24] <sanjiva> ah excellent! Addressing is a core function ... so
your help with that will be very welcome. (Not to devalue the security
stuff of course ;-))
[10:24] <dims> talking to infra folks on #asfinfra channel if you want
to join us
[10:25] <Essington> sanjiva: I'm working on soap over email, so both are
core functionality in my case
[10:26] <sanjiva> soap/smtp? Excellent .. I did an impl of that back in
the apache soap days :)
[10:26] <sanjiva> actually that'll be an excellent test of the async
support in axis2
[10:26] <dims> and i ported it to axis 1.X :)
[10:26] <dims> Absolutely
[10:26] * Jaliya has quit IRC
[10:26] * farhaan has quit IRC
[10:27] * srinathAndDeepal has quit IRC (Read error: 104 (Connection
reset by peer))
[10:27] <Essington> sanjiva: one of my first implementations used async,
but the current one manages asynchronous  messaging through addressing.
[10:28] <Essington> it is very cool, and should work in axis 1.x as well
once addressing and wss4j work there too.
[10:34] <rechteeh> hi... I'm trying to get axis to use another socket
factory for secure connections, but nothing seems to work... the
integration guide says that I should set a property, but that doesn't
make any difference... any suggestions?
[12:34] * Disconnected
Session Close: Wed Sep 01 22:37:54 2004

View raw message