axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ias" <iasan...@hotmail.com>
Subject RE: [Axis2] IRC log 2004-09-01
Date Thu, 02 Sep 2004 14:01:20 GMT
Here's my "too-late" regrets. (I was out for late lunch :-(

Looking forward to the next session with SVN on,

Ias

P.S. What will be my scratch directory are: JAX-RPC 2.0 early impl, SAAJ DOM
Level 3 impl and Axis for Tiger (compilable with J2SE 5.0).

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@sonicsoftware.com] 
> Sent: Thursday, September 02, 2004 2:34 PM
> To: axis-dev@ws.apache.org
> Subject: [Axis2] IRC log 2004-09-01
> 
> 
> 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>
> http://wiki.apache.org/ws/FrontPage/Architecture
> [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>
> http://wiki.apache.org/ws/FrontPage/Architecture/Engine 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
> etc..
> [09:06] <Jaliya> By way of code interfaces or diagrams
> [09:06] <gdaniels> We finalize the interfaces, I think, by making
> proposals
> [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
> :D
> [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
> phase.
> [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
> out
> [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
> instance.
> [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
> implementations
> [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
> (Message)Context?
> [09:18] <gdaniels> I don't think so, Alek, although it may 
> live in there
> too.
> [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
> specifics
> [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
> guss
> [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
> least
> [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
> deserializtion?
> [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
> http://wiki.apache.org/ws/FrontPage/Architecture/Encoding Deserializer
> [09:37] <sanjiva> ;-)
> [09:37] <srinathAndDeepal> ;-)
> [09:38] <as10m>
> http://wiki.apache.org/ws/FrontPage_2fArchitecture_2fEncoding
> [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
> DeserContext
> [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
> omElement.setObjectValue(myObj)
> [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
> get?
> [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
> peer))
> [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
> simple 
> [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
> code.
> [09:49] <eXtreme> hi guys
> [09:49] <gdaniels> Uses the responder/sender thingy and splits the
> req/resp
> [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 http://www.apache.org/dev/version-control.html
> [09:55] <gdaniels> So can we talk about short-term goals for 
> the coming
> week?
> [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
> contrib/axis2/*
> [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
> stuff
> [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
> http://www.w3.org/TR/xml-media-types/
> [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
> http://ar.geocities.com/itcrespo/eclipse/tortoisesvn/
> [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
> him)
> [10:08] <sanjiva> Alek???
> [10:08] <Ajith> for Intellij fans check this out
> http://svnup.tigris.org/
> [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> http://docs.codehaus.org/display/GEOTOOLS/Source+Code
> [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> http://wiki.apache.org/ws/FrontPage/OMDiagrams
> [10:16] <dims> Ashu added 
> http://wiki.apache.org/ws/FrontPage/OMDiagrams
> [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
> hills
> [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
> JBoss/WSS4J/Axis/Addressing
> [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 -
> http://nagoya.apache.org/jira/browse/INFRA-109
> [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
> 

Mime
View raw message