I guess your concern is keeping the request_rec as a global pointer and when multiple requests are being served there is a problem of keeping multiple request_rec s. Also when calling send_response_bytes and get_request_bytes there is no way to associate it with the relevant request_rec.These concerns are relevant only when multithreading.
yes,It would be better if we can avoid this global varible. We suggest the follwing to solve this issue. The signature process_request(soapstream *) is changed to process_request (soapstream *, void *) so that the request_rec pointer can be passed to axis so that send_response_bytes and get_request_bytes can be called with that pointer. Would that solve the problem for writing a module for IIS? do you have an idea on how this would affect other modules? On Tue, 29 Jul 2003 07:35:09 -0400, Lilantha Darshana wrote > Yes, your functions supports what you expected. But, writing other > modules are difficult with these functions. I have already gone > through the relevant section in developers-guide.html. > > What I meant by the global handler is holding a pointer to the > "request_rec" in the mod_axis, > I know that you have used this way, because you want to share > this structure between these functions. > > Yes, the internal logic is not a matter to the Axis engine but > implementing these as a set of functions will be difficult > for module writers when they do not want to share global variables > etc. > > One approach is to use a class interface to be implemented by the > module writers, so the instance of the class will hold above global > variable as private members. > [As we discussed earlier having global pointer/handler to a object > may introduce lots of problems when you come to multithreading. > (these threads may not be implemented by axis engine itself but > may be by the module or the webserver whose going to use the axis > engine)] > > Other approach is of using I/O streams. > I/O streams can help you on resolving these issues. Let say for an > example if you use a std::istream in place of get_request_bytes(...) > you will be able to do what you do with get_request_bytes(...) method. > > Let say I'm going to provide you a std::istream & std::ostream > so you will be able to do your task as you do with these functions. > The, advantages behind using stream are: > -you don't want to have global variables > -it is easy to write a single dispatch method in module writing and > that dispatch method just wait until you return (blocked until you process > the request) or can do synchronize things if any. > -and it resolves the problem of supporting real pulling/pushing of > data from/to a channel. > > Thanks > -Lilantha > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 4:31 PM > To: Lilantha Darshana > Subject: RE: [Axis C++] mod_axis & Interface call backs > > If i am not mistaken these functions achieve what you have described. > did you go through the topic "writing transport modules" in > developers- guide.html in the docs folder? the functions > get_request_bytes and send_response_bytes have to be implemented by > any transport module so that Axis may call these functions. The > implementation of these methods should not matter to Axis. Is it not > possible to implement such functions in a IIS module? > > when you say global handlers Are you refering to send_response_bytes > etc..? actually they are not handlers themselves, but global > functions implemented in the apache module. > > could you be more specific about the streams? > > On Tue, 29 Jul 2003 05:23:58 -0400, Lilantha Darshana wrote > > sanjaya singharage wrote: > > >This is necessary for implementing the pull parse. So this is a major > > design > > >aspect. > > > > >> Do you have any design concerns if I change these to satisfy > > >> multiple server support HTTP handlers like servlet & IIS? > > >> > > > > >could you elaborate in what way you want to make these changes? As I said > > > >before this is a major design issue so that we can implement pull > parsing. > > > > Let say if you have given two streams, say in & out to hold the > > request SOAP envelop and response SOAP envelop respectively with a > > header information in a list of name-value pairs, would you be able > > to use this in xmlpull parser integration you concerns. The above > > two streams does what you do currently with: send_response_bytes(...) > > & get_request_bytes(...) > > > > i.e. for an example when you want to call send_response_bytes(...), > > you just call the output streams write(...) method instead. and you > > can flush(...) the stream to allow the web server to write the data > > you have in output stream to the client end. and so on... > > > > This way it avoids having global handlers as well as it is easy to > integrate > > the Axis C++ server in other web servers like Tomcat, IIS etc. > > > > Thanks > > -Lilantha > > -- > Lanka Software Foundation (http://www.opensource.lk) > Promoting Open-Source Development in Sri Lanka -- Lanka Software Foundation (http://www.opensource.lk) Promoting Open-Source Development in Sri Lanka
