Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 69827 invoked by uid 500); 26 Nov 2002 23:27:36 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 69817 invoked from network); 26 Nov 2002 23:27:36 -0000 Message-ID: <3DE40332.6020908@sosnoski.com> Date: Tue, 26 Nov 2002 15:26:42 -0800 From: Dennis Sosnoski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: axis-dev@xml.apache.org Subject: Please beta 1.1! (Was: Re: Today's IRC log) References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Please reconsider the issue of doing a beta for 1.1, so that people can try it out and report new bugs. I've tried working with a recent daily build but ran into a couple of major problems just for simple RPC-encoded web service and client, and it sounds like others have had similar experiences with dailies - while most users won't try them at all. I'll retest my particular issues with the current daily and enter bug reports if something is still wrong, but the fact that this is happening at all says that the current CVS code is not in a really stable state. You need to go through the checkin freeze and test cycle if you want 1.1 to be a stable release for the next couple of months, while new major features are integrated into the codebase. Doing a beta will get substantially more users to try out the code and make for a much more stable 1.1. - Dennis Glen Daniels wrote: >Hi folks! > >Here's the chat log for today. > >--Glen > >Session Start: Tue Nov 26 11:29:59 2002 >[12:52] *** kameshwar has joined #ApacheAxis >[12:53] hi all >[12:54] Hi kamesh >[12:55] I had sent a mail to the list askign about the future of the Async support >[12:55] in Axis >[12:55] I got a reply from James that it is a work in progress >[12:56] yes. That sounds right. >[12:56] Just wanted to when would that be made avbl in the Axis release? >[12:56] kameshwar: what is meant by Async support? >[12:56] Asynchronous Messaging support >[12:56] :-) yes . . . >[12:57] Kamesh: No dates yet on anything yet... >[12:57] oh ok >[12:57] so the request message and response message are two separate events? >[12:57] *** GlenLunch is now known as GlenD >[12:57] *** DaveChapp has joined #ApacheAxis >[12:57] hi glen >[12:57] hi dave >[12:57] hola dims, folks! >[12:57] Hi glen >[12:57] Hola! >[12:58] Hi dave >[12:58] Hi >[12:58] Thanks for coming - let's give it a few more mins before launching in to let any others show up >[12:58] *** tom_lunch is now known as tjordahl >[12:59] Jaime is on his way..... >[12:59] *** JaimeMeri has joined #ApacheAxis >[12:59] Hi all >[12:59] hi Jaime >[12:59] hi Jaime >[13:00] Hi Jaime >[13:04] allllrighty then >[13:04] it's 5 past, maybe let's get started? >[13:04] yup >[13:05] So what should we discuss first? Bugs, 1.1, async, schema...? >[13:05] I vote 1.1, which leads inevitably into bugs :) >[13:05] Bugs First... >[13:05] too many of them :( >[13:06] Indeed. >[13:06] Someone should fix them all >[13:06] Fix them all, fix them well. >[13:06] Good luck, Tom! >[13:06] OK, next topic. >[13:06] :) >[13:06] AND write test-cases... >[13:07] I like the test-case-first idea, even. >[13:07] Glen: Can you take care of the EjbProvider patch Bug #14671? >[13:07] If we made it super easy to write a test case, in fact, we could actually ask bug submitters to attach them to the bugzilla reports.... >[13:07] dims: yes. >[13:08] I was going to suggest that we actually try for a conference call next Tuesday at which we can do a bug scrub / assignment >[13:08] +1 to conf call. >[13:08] In the interim we can all take responsibility for becoming familiar with the list, and picking bugs we'd like to handle >[13:08] we can do some of this via email beforehand, and then plow through on the call >[13:08] what do the rest of y'all think? >[13:08] sounds good... >[13:09] Who is going to be able to fix bugs? Glen, Dims and ??? >[13:09] Dave, Jaime, would you guys be into helping out for bugs that don't require in-depth Axis knowledge? >[13:09] No Russell, Rich, Richard, etc, etc >[13:10] No Sam either.... >[13:10] Tom: Yeah, but who knows - we might be able to rope them in for next week. >[13:10] Sure that would be fine with me >[13:10] That would be great. >[13:10] And it doesn't have to be just committers, either. >[13:10] Yup. >[13:10] That's good because I'm not a committer >[13:10] If other folks are psyched (hint hint), they can take bugs, fix them and submit patches, and then BECOME committers... >[13:10] :) >[13:10] :) >[13:10] :) >[13:10] great :) >[13:10] 8-) >[13:11] OK. So, everyone should please read over the bug list. >[13:11] OK. >[13:11] If you see a bug that is clearly in your zone of expertise / comfort, assign it to yourself. >[13:11] k >[13:11] Schedule for 1.1 and release manager? >[13:12] Next week we'll schedule a call and go over the list and see where we're at. >[13:12] Schedule: How about before christmas? >[13:12] Criteria for 1.1 first, maybe. Are we good with releasing the current codebase, or should we wait for the bug scrub? >[13:12] Oh, before Xmas should be OK, I would think. >[13:13] I can release manage. >[13:13] Glen: I think we should bring down the bug count to around 60-70... >[13:13] Do we need a beta or RC? OR shuld we just cut a 1.1 and ship it. >[13:14] Cut 1.1 directly. >[13:14] I think we can just cut 1.1 and ship it when we think it's ready, personally. >[13:14] We can always do a 1.2 (release early and often) >[13:14] yep. >[13:14] What's the rush to get it out before XMas? >[13:14] Holiday shoppers. >[13:15] Oh, wait.... >[13:15] "The perfect gift for your Java geek friends!" >[13:15] Dont' want 3 months before releases... >[13:15] Seriously, I think before the end of the year would be nice, and that means before XMas, realistically. >[13:16] It would sync up with some stuff interally. But mainly its to get users using a bug fixed release post-1.0 >[13:16] Always a good idea. Nobody dares to use a 1.0 product. >[13:16] There is alrady lots of stuff we are telling people to check in the nightly's. >[13:16] (Faults, doc/lit WSDL, headers, etc) >[13:16] Plus that servlet thingy >[13:16] Remember we need to run TCK Test Harnesses again :( >[13:17] good reasons to ship soon >[13:17] yup >[13:17] Did Sam every get that automated and passing? >[13:17] s/every/ever/ >[13:17] Not that i know of... >[13:17] *** JamesMSne has joined #ApacheAxis >[13:17] greetings all >[13:17] Hi James >[13:17] hi James >[13:17] Hi James >[13:18] Hi James >[13:18] so... we're talking about 1.1 release? >[13:18] yep, before XMas... >[13:18] so we're generally aiming for end of year, and this will be informed by the bug scrub. >[13:18] hi james >[13:18] that would be a good thing >[13:19] JAmes, can you help out on the bug scrub? >[13:19] should be able to. >[13:20] won't be able to start until next week >[13:20] but I could take some of the items >[13:20] (the plan for which is "everyone read the bug list this week, then conference call next Tuesday to run down and assign things / see where we're at") >[13:20] that works >[13:20] OK. Anything else re: 1.1? >[13:21] we'll keep the ime stuff out of 1.1 >[13:21] oh :( >[13:21] +1, but we should resolve it soon thereafter >[13:21] i thought that would be in 1.1 :) >[13:21] let's target the first release of ime and the transports for 1.2 >[13:21] sounds good to me >[13:21] +1 >[13:21] +1 >[13:21] Speaking of which, shall that be our next topic? >[13:21] xmas is a bit quick to do a good bug scrub and test >[13:21] glen: that works >[13:22] You may be right, James. If that's the case we'll decide whether or not to push back 1.1 depending on the severity of the current issues. >[13:22] k >[13:22] So - IME stuff >[13:22] I think we have fixed enough stuff and added some functionality (faults, headers, WSDL fixes) to warrent getting it sooner rather than later. >[13:23] (I agree Tom) >[13:23] (That was for James' benifit) >[13:23] tom: ok >[13:24] so... ime stuff... what's on your mind glen? want me to give a quick overview of status then discuss issues? >[13:24] I had some questions. First off, I'd punt the FeatureEnabled interface - it doesn't do anything at present, and I don't think that's the right model for this stuff (I've been working on Features/Modules/Bindings in my sandbox)... >[13:24] I think we should discuss that architecture separately. >[13:24] ok >[13:25] I agree that it can be punted for now, but I really want to revisit >[13:25] Second, why is MessageCorrelator not just an interface with a matches(MessageCorrelator) method? >[13:25] +1, definitely! I have a lot of ideas in this area, I just think they're sort of separate and shouldn't get mushed in with async. >[13:25] wanted to provide a simple base that can be used as is >[13:25] It just seems incongruous with everything else being interfaces, is all. >[13:25] Not a big deal, just an architectural weevil. >[13:25] we could make MessageCorrelator an interface, and in org.apache.axis.internal we could create a SimpleMessageCorrelator >[13:26] adding a matches(MessageCorrelator) method is a good idea >[13:26] jaime: thoughts on that? >[13:27] James: No complaints here. It makes sense >[13:27] Seems like that's exactly what you DO with Correlators... :) >[13:27] :-) >[13:28] ok, that's added to my todo's >[13:28] receive(MessageExchangeEventListener) >[13:28] that seemed weird to me too. >[13:28] Glen: Receive should probably return the received message >[13:29] I understand the other receive()s >[13:29] glen: why is it wierd? >[13:29] but the one which just takes a MessageExchangeEventListener seems odd. What's the difference between that and setMessageExchangeEventListener()? >[13:31] hmm... I thought I had removed the getter and setter. My preference is to specify listeners per send/receive so that state is not a factor >[13:31] um >[13:32] What's the relationship between a MessageExchange and a MessageContext? Let's start there. >[13:32] I'm not sure that sentence made sense... (sorry, trying to do two things at once) >[13:32] James: I think it is pretty convenient to be able to set a listener for all messages >[13:32] (no it made sense, but I'm not sure I grok the architecure yet) >[13:32] MessageExchange is the interface through which MessageContexts are passed back and forth >[13:32] e.g. MessageExchange.send(MessageContext) >[13:33] MessageExchange.receive(MessageExchangeEventListener) says "deliver the message to the specified listener" >[13:33] so a MessageExchange is "a thing I want to deal with messages for me" >[13:33] gotcha >[13:34] jaime: I agree that it's convenient, I just don't think it's necessary >[13:34] James: Do you think that the listener implementation will change very often? >[13:34] no >[13:35] Can you have multiple listeners? >[13:35] So then specifying a default listener makes sense >[13:35] although someone may want to specify a new listener for individual messagecorrelators >[13:35] new listener instance that is >[13:35] glen: yes >[13:36] So you could support a default listener and a set of methods that allow you to override the default on a per-invocation basis >[13:36] +1 >[13:36] the way it is currently set up, the MessageExchange can use a single listener for all requests or pass in an override for each request >[13:36] jaime: +1 >[13:37] yeah, what you just said :-) >[13:37] although... I'm not sure we need the complexity of multiple listeners yet. What if we just restricted it to one-per ME for now? >[13:37] That would simplify the internal code a good bit, and then we could always add more later if there's demand. >[13:38] actually, it doesn't add any real complexity >[13:38] a minor if/then switch >[13:38] well, it might, actually, in terms of understanding what's going on. >[13:39] It seems to me the important part about this is breaking the coupled synchronous pipe we have now into pieces. But it's still a linear set of pieces with looser coupling. >[13:39] Once you add the ability to fan-in/fan-out, it can get weird. >[13:39] It's powerful, no doubt, but maybe that should be considered a second step. >[13:40] Does that make sense? >[13:40] hmm.. I personally still don't see any problem with it. will have to think about it >[13:40] I agree with Glen. The per invocation override is still possible if you use the receive methods when you want to handle particular messages differently >[13:40] Once we tack a client API on that, we would want to bubble up that multiple listener capability to the API, right? >[13:40] (although I was going to go as far as to say you shouldn't even need to do that) >[13:41] dave: perhaps >[13:41] Dave: Client API listeners do not necessarily map 1-1 with ME listeners >[13:42] can we find a real time use case to see if we need multiple listener? >[13:42] possible scenario: multiple clients may use a single ME >[13:42] each client may use a different listener >[13:42] James: flesh that out >[13:42] Give me a real scenario. >[13:43] Multiple clients, at present, do NOT share AxisEngines, nor should they according to the Axis design. >[13:44] ok, then multiple HttpSession using the same AxisServer instance >[13:44] HttpSession == a client request on the AxisServlet >[13:44] eventually, communication with the AxisServer will happen through the ME interface >[13:44] hm. >[13:45] well, so maybe this is a place where I disagree with the design then. >[13:45] James:Can we one more implementaion of MessageListener called ForkMessageListener which has a list of MessageListener internally it can send/receive? >[13:45] it seems like MessageContext is already about a particular flow through the system. So I'd do it with that. >[13:45] btw, I'm just throwing stuff out to see if it makes sense.... I'm not necessarily advocating anything >[13:46] i.e servlet creates a MessageContext, and *that* has the configuration for correlating, events related to that message, etc... then it just hands that to the shared server instance. >[13:46] kameshwar: I'd say that adds a bit more complexity that we need right now >[13:46] ok >[13:46] glen: thinking >[13:46] MessageContext context = >[13:47] context.setEventListener(me); >[13:47] engine.invoke(context); >[13:47] or something like that >[13:47] engine.getMessageExchange().send(context); >[13:47] well, I'm calling into question whether we need MessageExchange. >[13:48] yes, think about receive only operations >[13:48] engine.getMessageExchange().receive(listener); >[13:48] without any initial invocation >[13:48] e.g. client wants to pull a soap message off a JMS queue >[13:48] thinking >[13:49] client wants to pull a message from a queue. >[13:49] James:In that use case how would the MessageExchange be configured to attach itself to the JMS Queue? >[13:49] also, client wants to do send now, then receive later (not as a callback) >[13:49] OK, is this message a response to something? >[13:49] MessageExchange.send(context); >[13:49] no >[13:49] what is it? >[13:50] notification >[13:50] an event notification or something? >[13:50] ok >[13:50] Kameshwar: The JMS trasnport would be an implementation of MessageExchange. >[13:50] kameshwar: the config for the JMS transport would have the JMS connection info >[13:51] invoke assumes request/response >[13:51] we need separate send/receive operations >[13:51] that's where MessageExchange comes in >[13:51] invoke() doesn't actually assume that >[13:52] call.invoke() does. But AxisClient.invoke() doesn't. >[13:52] Glen: It does assume the generation of an outbound request though doesn't it? >[13:52] Not necessarily. >[13:52] ?? >[13:52] you must provide an input MessageContext >[13:52] I guess it is up to your transport implementation and what the pivot actually does >[13:53] that seems like a hack to me >[13:53] James: yes, that's true, but it's not necessarily an "input" messagecontext. It's just a set of properties 'n stuff. >[13:53] a big hack >[13:53] What seems like a hack? >[13:53] using invoke >[13:54] James: I agree, the use of receive and send is a lot more intuitive >[13:55] Let me back up. There is going to be a MessageContext associated with any sending or receiving that happens. >[13:55] Agreed? >[13:56] agreed. MessageExchange exchanges MessageContexts >[13:56] hold your horses. :) >[13:56] Though come to think of it, I can actually go finish this thinking on my own and write up an email about it. >[13:57] I'll do that and try to get it out this afternoon. It's just reaffirming some first concepts about this stuff. >[13:58] you will have an extremely difficult time convincing us (me, Jaime at the least) that using invoke is a good option >[13:58] It's not about using invoke per se. >[13:58] that's secondary. >[13:58] it's more about how the pieces fit together >[13:59] be sure to include a discussion of what pieces of ime you don't think fit together, because I'm just not seeing it >[13:59] check. >[13:59] a couple of points.... >[13:59] Again, it's not that I think what's there is bad or anything. It's that I'm wondering if it could be simplified. >[14:00] 1. I initially looked at retrofitting async into the invoke mechanism and concluded that it would be a lot more work than its worth >[14:00] 2. Retrofitting async into the current invoke would not simplify anything since all of the same stuff needs to be implemented in either case >[14:01] 3. The MessageExchange approach is far more intuitive >[14:01] ok >[14:01] I'll take my questions to email. Any other IME stuff you guys want to cover on the chat? >[14:01] James : To make myself clear MessageExchane is a MessageContext right? >[14:01] 4. The approach we're taking takes all of the complexity and stuffs it into utility classes >[14:01] kameshwar: no >[14:01] kameshwar: nope. >[14:02] the MessageExchange is the interface through which MessageContexts are exchanged >[14:02] glen: just timeline >[14:02] Got another meeting to run to. Later. >[14:02] Take it easy Dave! >[14:02] *** DaveChapp has quit IRC (Quit: Trillian (http://www.ceruleanstudios.com)) >[14:03] I'd like to get all of the transport senders migrated over to the async model by January with test cases >[14:03] i.e. end of January? >[14:03] I've already created the wrappers for the existing HttpSender, LocalSender and JavaSender >[14:03] beginning of January >[14:04] I'll take care of the JMS sender >[14:04] those wrappers take the current sender Handlers and wraps them into MessageExchangeProviders >[14:04] one of the biggest issues here is the WSDD code >[14:05] on WSDDTransport, createNewInstance() would need to return a MessageExchange rather than a handler >[14:05] um >[14:05] that would actually be the biggest change >[14:06] ok >[14:06] the point is to get AxisClient using the MessageExchange interface when calling the Transport senders rather than Handler.invoke() >[14:06] We should also support the legacy syntax for transport definition if possible >[14:07] for now, that communication would still be syncronous, using MessageExchange.sendAndReceive(), but it's a baby step >[14:08] James: The sendAndReceive behavior will only change when the async client api is exposed. Is that correct? >[14:08] jaime: kinda. >[14:09] when AxisEngine becomes a MessageExchangeProvider, we can make it async all the way through the engine and transports. the Call object would use sendAndReceive on the Axis engine >[14:09] then, when the client api is done, everything would be set up to make it all async >[14:10] the objective is to work from the bottom up >[14:10] transports first, then providers, then the engine that sits on top of the transports and providers, then the client api >[14:10] Makes sense to me. Of course I drank the kool aid long ago :) >[14:11] glen: I can understand if this all scares you given your concerns about the interfaces. we'll work through your concerns, but we're still going to move forward on the original plan >[14:11] the point is: we'll be doing a phased async conversion of all of the axis subsystems >[14:11] one by one working our way up to the client api >[14:12] great >[14:12] whatever that async mechanism ends up being in the end >[14:12] that way we're not trying to tackle too much at once >[14:12] check >[14:13] I gotta run, so getting back to specific task items >[14:13] *** DaveChapp has joined #ApacheAxis >[14:13] 1. I will remove FeatureEnabled for now >[14:13] 2. I will make MessageCorrelator an interface and create a SimpleMessageCorrelator >[14:13] We're currently working on scoping out a potential client API that may be a good topic for discussion in the coming weeks >[14:13] 3. I will add matches(MessageCorrelator) to the MessageCorrelator interface >[14:14] good topic of discussion == debate fodder :-) >[14:14] :) >[14:14] and, I'll start taking a look at the bug list >[14:14] sounds good >[14:14] later James >[14:14] later guys >[14:14] *** JamesMSne has quit IRC (Quit) >[14:16] OK, on to... >[14:16] schema stuff? >[14:16] Do we want to discuss this, or call the "official" chat there for today? >[14:17] It would be nice if Vidyanand could be here for that discussion, I suppose... >[14:17] Yes, he should be around for that >[14:17] Vidyanad i could callhim >[14:17] and ask him to join the chat >[14:17] oh, you're in that stuff too, kameshwar! >[14:17] i and vidyanad are colleagues >[14:17] I'm sorry, I totally spaced that. >[14:18] :) >[14:18] in the same starup :) >[14:18] So have you guys taken a look at the way SymbolTable/SchemaUtils does its work yet? >[14:19] *** DaveChapp has quit IRC (Quit: Trillian (http://www.ceruleanstudios.com)) >[14:19] I think Vidyanand has not yet finished porting >[14:19] Is he actually working on it now? >[14:20] i think but am not too sure as we have too much on our plate :-) >[14:20] I hadn't realize he'd gotten that far yet. >[14:21] i am not too sure >[14:21] Glen >[14:21] i might be wrong :) >[14:21] ok >[14:22] So in any case, the first minor nit I have is the package structure. >[14:22] Seems like the enum and str packages could go away to move somewhere else, and the xml/schema package could collapse to just schema, moving the util functionality in xml elsewhere as well. >[14:23] so the bulk of the code would be org.apache.axis.schema.* or axis.xmlschema.* >[14:23] glen >[14:23] i am on line with Vidyanad >[14:23] he is in Boston >[14:23] and he is very eager to meet u personallu\y >[14:24] +1! >[14:24] ifu can >[14:24] Kamesh: Ask him to call me too. >[14:24] How about Tom and Dims and Vidyanand and myself all go for lunch next week? >[14:24] +1 >[14:24] he is for this week >[14:24] Anyone else in Boston? Welcome to join us :) > -- end log - the rest was logistics for meeting up, which happened this afternoon -- > > >