From: Chuck E. <ec...@mi...> - 2000-07-06 20:34:04
|
In WebKit/Testing/, I replaced PathTesting.text with Main.py and TestCases.data (which Main.py loads and displays). This makes the test case URLs clickable. I hope to continue expanding and eventually automating the test suite (and I can always use help). :-) In Examples/, I updated ExamplePage.py so that example pages now include a list of whatever Contexts are configured for the Application. This appears right under the list of example pages. For example: Contexts: Admin | Documentation | Examples | PSPExamples | Testing | nf | spp In HTTPRequest.py, I added adapterName() which returns something like "/WebKit.cgi" or "/OneShot.cgi". This is useful in special cases for constructing URLs (like in Testing/Main.py). In WebKit/, I added AppServer.bat so that Windows users can just type "AppServer" at the prompt to run it. We should set up the same thing for UNIX. I have "directory-URL-redirects" working (mail me if you don't know what the means), but I've discovered some problems with caching. I don't know if I broke something, or if it was already like that. But I'll fix before checking in these changes. I'm also incubating a new plug-in called FormKit/ which makes it quick to construct, display and validate forms. I'll probably upload that in a couple weeks when it's worth looking at. For those of you that don't know, the CVS repository is accessible at: https://sourceforge.net/cvs/?group_id=4866 -Chuck |
From: Chuck E. <ec...@mi...> - 2000-07-14 23:11:45
|
* There is a new 'Host' setting to complement the 'Port' setting in WebKit/Configs/AppServer.config. It defaults to 127.0.0.1. Originally we were using a blank host name, but some platforms (Windows and older FreeBSD) didn't like that. * Fixed AdminPage's HTML. It was illegal and Navigator 4.7 wouldn't show the page at all. * Renamed WebKit/cache/ to WebKit/Cache/ to match the case of other dirs. A subdir in Cache/ is created for each plug-in as they are loaded. PSP now puts its cached files in Cache/PSP/, for example. * Jay tweaked sessions so that they are created only when asked for. This implies that in subclasses of Page, you should use self.session() and not self._session. For purposes of encapsulation and consistency, you should probably do the same for all attributes (e.g., use the methods). -Chuck |
From: Chuck E. <ec...@mi...> - 2000-08-08 03:21:16
|
Here is a summary of updates I have made last Friday and today. * Moved KeyValueAccess from MiddleKit to MiscUtils and renamed it to NamedValueAccess. The move was due to the fact that KeyValueAccess turned out to be more generally useful than originally anticipated. The rename was appropriate given that valueForName() was the most popular method. * There is a new sidebar/navigation bar for the examples. The previous top links and bottom links have been subsumed by this. The nav bar includes all the goodies like examples, contexts, exits, versions, etc. This was accomplished via the new SidebarPage class which both AdminPage and ExamplePage inherit. The new look is cleaner, more professional and, I think, easier to navigate. * Created Adapter, a subclass of Configuration. Made OneShotAdapter a subclass thereof, with the others to follow. This is part of an adapter reorg. * OneShotAdapter has a config file in Configs/. When capturing output, provided option to word wrap it so the table doesn't get so wide. <boring> * A 'transaction' global variable is passed into servlet scripts as a hook for the script to get information about the request that caused it to load. This should be rarely needed, especially with Jay's recent addition of __init__.py support of contexts, where you can do special initialization. But in general, hooks are a good thing if they don't clutter the code or mangle the architecture. So it's there. * Added Testing/ to MiscUtils. Added TestDataTable.py. * Changed Application's SessionTimeout to be expressed in minutes instead of seconds. * Revamped Application's session sweeper method to be cleaner/tighter. </boring> For your review/understanding: * The OneShot adapter loads everything (WebKit, plug-ins, contexts, the target servlet) once, serves the request and then exits. It is useful when: * developing web sites * developing WebKit and plug-ins * running in a CGI-like mode rather than an app server mode if you so desire * NamedValueAccess is a useful mix-in class that allows you to query objects like: obj.valueForName("account.address.city"). Each field could be a method such as obj.account() or attribute such as obj.account or obj._account. The valueForName() method will follow the hierarchical dot notation through objects and dictionaries. This kind of querying can be useful when setting up templates. It's also the basis for setting up the columns that get stored in the access log. The config file for Application stores these names and then runs through them with valueForName(). And there's even decent documentation embedded in the source file and a test suite to boot. I've also exercised this class in a few sites, so it's advertised feature set are stable. On my short term radar: [ ] FormKit/ [ ] Page: Add features for style sheets. [ ] Handle unknown session ids with a specific page. [ ] Fix ExamplePage to handle Plug-ins generically. [ ] Add Last-modified: to generic files that get served up. [ ] When I do a CVS co on FreeBSD, I get 'cache', but not 'Cache' [ ] Disk based session storage. Having lots of fun, -Chuck |
From: Chuck E. <ec...@mi...> - 2000-09-01 15:36:46
|
Nothing big: * Fixed a bug in MiscUtils/DataTable.py regarding blank values. (Did that a couple days ago) * Fixed bugs in OneShot.cgi & WebKit.cgi regarding HTML-encoding for exception reporting. -Chuck |
From: Chuck E. <ec...@mi...> - 2000-09-26 02:05:53
|
1. WebKit/Documentation/InstallGuide.html is finished. It's 31K and about 12 pages when printed. Thanks to Geoff for IIS notes and Jay for app server notes. 2. WebKit/Future.html is pretty much updated. 3. Configurable.setting() now has an optional 'default' parameter, so you can do something like this: name = app.setting('Name', None) If you don't specify a default, an exception is thrown when the named setting is not found. Configurable is a base class for Application, AppServer and OneShotAdapter. 4. NamedValueAccess.valueForKey() has always allowed a default value to be specified. However, it has now been tweaked so that it throws an exception (rather than returning None) when no default is specified. This matches all the other methods in Webware. NamedValueAccess is a base class for Application and is used in writing the activity log. 5. DocSupport/PySummary.py, which is used by install.py to generate HTML summaries of the Python files, no longer includes classes, methods and functions that start with a single underscore. This makes the summaries cleaner in some cases. For releasing, the only outstanding items that I know of are: * cut a release candidate 2 * PSP release notes -Chuck |
From: Geoff T. <gta...@na...> - 2000-10-25 17:26:35
|
Added a new Application.config option "IgnoreInvalidSession" which, if true, treats an expired or invalid session id the same as no session id, instead of displaying an error message. (Setting this option to 1 makes the SecurePage stuff I sent out yesterday work more nicely, because if your session expires, you just get asked to login again, and once you've logged in, you can pick up at the same place in the web site where you left off, minus whatever values you've saved in session variables. Before making this change, the user was confronted with an error page, then a login page, which seemed a bit annoying.) -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2000-11-28 20:37:44
|
- I've fixed a problem in ThreadedAppServer that would cause it to sometimes degenerate into a mode where it stops handling requests in a timely manner. This behavior could be provoked by hitting it with more simultaneous requests than it could handle at once. AsyncThreadedAppServer didn't need the fix. (The gory details are that rhQueue was too small, causing the RequestHandlers to block while attempting to insert themselves into rhQueue in the RequestHandler.close() function. I changed rhQueue to be unlimited size, which is safe because it cannot grow beyond a fixed bound anyway -- the number of threads plus the size of requestQueue plus one, according to my analysis). - I've fixed Application so that all servlet instances are properly destroyed when the application exits. - I've fixed a couple of bugs in ThreadedAppServerService for those of us running WebKit as a service on WinNT. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2000-12-06 17:45:36
|
I checked in the COMKit plug-in. If you want to use COM objects on Windows in your servlets, you'll just need to set "EnableCOM" to 1 in your AppServer.config file. There is also a simple example of using ADO for database access in servlets. I also checked in the SecurePage example as a standard WebKit example. This includes a fix for the "repeated login" problem that Dawn Stowers reported yesterday. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2000-12-08 01:32:03
|
I made a bunch of improvements to the adapters and ThreadedAppServer: - All adapters now inherit from Adapter base class, and the code to do the marshaling and socket communications with the app server now lives in Adapter. - The adapters will now retry if they can't get to the app server initially. This is configurable. - ThreadedAppServer is now smarter about how it handles the requestQueue during shutdown, eliminating a source of hanging problems when the request queue was full and the app server was stopped. - On NT, ThreadedAppServerService now uses ThreadedAppServer instead of a separate but mostly identical copy of the code. - On NT, ThreadedAppServer now shuts down correctly when you use Ctrl-C. It appears that this fix won't work on Linux. Note: I made the corresponding changes to FCGIAdapter but I can't test it with my setup. Someone who's using it, please give it a whirl. Also, I haven't checked if AsyncThreadedAppServer would benefit from these changes. This stuff now looks rock solid on NT -- I can have 100 simultaneous requests for non-trivial servlets going on, and I can stop and restart the app server in the middle of handling the requests, and all the end user notices is a bit of a delay while it restarts. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2000-12-13 18:38:57
|
I checked in XMLRPCServlet.py, a base class for servlets that act as XML-RPC servers. I also checked in XMLRPCExample.py, an example XML-RPC servlet. If you need programmatic access to your WebKit server, this is a great and easy way to do it. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Tom S. <tom...@li...> - 2000-12-15 15:00:43
|
Geoff Talvola wrote: > > I checked in XMLRPCServlet.py, a base class for servlets that act as > XML-RPC servers. > > I also checked in XMLRPCExample.py, an example XML-RPC servlet. It's amazing to see how simple this is with WebKit. B.t.W. This was on my personal wishlist :-) > If you need programmatic access to your WebKit server, this is a great > and easy way to do it. class XMLRPCExample(ExamplePage, XMLRPCServlet): if you do that you will get XMLRPC errors. Do you have a simple example where this framework works as ExamplePage and as XMLRPC server? The question is then, how a method is either callable trough a browser (/add?var1=12&var2=23) and trough a XMLRPC method call (server.add(var=12, var2=23) and server.add(12,23))? Any hints? -- Tom Schwaller http://www.linux-community.de |
From: Geoff T. <gta...@na...> - 2000-12-15 15:57:46
|
Tom Schwaller wrote: > Geoff Talvola wrote: > > > > I checked in XMLRPCServlet.py, a base class for servlets that act as > > XML-RPC servers. > > > > I also checked in XMLRPCExample.py, an example XML-RPC servlet. > > It's amazing to see how simple this is with WebKit. > B.t.W. This was on my personal wishlist :-) > > > If you need programmatic access to your WebKit server, this is a great > > and easy way to do it. > > class XMLRPCExample(ExamplePage, XMLRPCServlet): > > if you do that you will get XMLRPC errors. Do you have > a simple example where this framework works as ExamplePage and > as XMLRPC server? The question is then, how a method > is either callable trough a browser (/add?var1=12&var2=23) > and trough a XMLRPC method call (server.add(var=12, var2=23) > and server.add(12,23))? Any hints? The XMLRPCServlet I checked in will only work for XML-RPC, not for browser requests. If you're willing to do a small amount of extra work, you can get the effect you want, by implementing the function in a mixin class, then creating two servlets that utilize the mixin class. For example (untested): class AdderMixin: def add(self, x, y): return x + y class XMLRPCAdder(XMLRPCServlet, AdderMixin): def exposedMethods(self): return ['add'] class HTMLAdder(Page, AdderMixin): def writeBody(self): req = self.request() try: x = int(req.field('x')) y = int(req.field('y')) except: self.writeln('Your input was bad') else: self.writeln('The answer is <B>%d</B>' % (self.add(x, y))) Or there may be some clever way to get one class to be able to respond to either XMLRPC or regular browser requests. I'll think about it. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Tom S. <tom...@li...> - 2000-12-15 18:57:13
|
Geoff Talvola wrote: > > Tom Schwaller wrote: > > > Geoff Talvola wrote: > > > > > > I checked in XMLRPCServlet.py, a base class for servlets that act as > > > XML-RPC servers. > > > > > > I also checked in XMLRPCExample.py, an example XML-RPC servlet. > > > > It's amazing to see how simple this is with WebKit. > > B.t.W. This was on my personal wishlist :-) > > > > > If you need programmatic access to your WebKit server, this is a great > > > and easy way to do it. > > > > class XMLRPCExample(ExamplePage, XMLRPCServlet): > > > > if you do that you will get XMLRPC errors. Do you have > > a simple example where this framework works as ExamplePage and > > as XMLRPC server? The question is then, how a method > > is either callable trough a browser (/add?var1=12&var2=23) > > and trough a XMLRPC method call (server.add(var=12, var2=23) > > and server.add(12,23))? Any hints? > > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser > requests. If you're willing to do a small amount of extra work, you can get > the effect you want, by implementing the function in a mixin class, then > creating two servlets that utilize the mixin class. For example (untested): > > class AdderMixin: > def add(self, x, y): > return x + y > > class XMLRPCAdder(XMLRPCServlet, AdderMixin): > def exposedMethods(self): > return ['add'] > > class HTMLAdder(Page, AdderMixin): > def writeBody(self): > req = self.request() > try: > x = int(req.field('x')) > y = int(req.field('y')) > except: > self.writeln('Your input was bad') > else: > self.writeln('The answer is <B>%d</B>' % (self.add(x, y))) For a reduced API this is certainly the way to go, when you have more methods it gets cumbersome.. > Or there may be some clever way to get one class to be able to respond to > either XMLRPC or regular browser requests. I'll think about it. yeah, that's what I was thinking about too. Propably you have code for something like class XMLRPCPage(HTTPServlet): before I start my night session today :-) The class should have the funtionality of Page and XMLRPCServlet, which unfortunately have both HTTPServlet as base class class XMLRPCServlet(HTTPServlet): class Page(HTTPServlet): so one needs to factor out some of the XMLRPCServlet Code into another Mixin class. I have the feeling that you need extraURLPath for a class beeing able to respond to either XMLRPC or regular browser requests. The circle is closing here :-) B.T.W: How many methods should one expose in such a XMLRPCPage then? To many of them is not good memorywise I think. comments? -- Tom Schwaller http://www.linux-community.de |
From: Geoff T. <gta...@na...> - 2000-12-15 21:00:15
|
Tom Schwaller wrote: > Geoff Talvola wrote: > > > > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser > > requests. If you're willing to do a small amount of extra work, you can get > > the effect you want, by implementing the function in a mixin class, then > > creating two servlets that utilize the mixin class. For example (untested): > > > > class AdderMixin: > > def add(self, x, y): > > return x + y > > > > class XMLRPCAdder(XMLRPCServlet, AdderMixin): > > def exposedMethods(self): > > return ['add'] > > > > class HTMLAdder(Page, AdderMixin): > > def writeBody(self): > > req = self.request() > > try: > > x = int(req.field('x')) > > y = int(req.field('y')) > > except: > > self.writeln('Your input was bad') > > else: > > self.writeln('The answer is <B>%d</B>' % (self.add(x, y))) > > For a reduced API this is certainly the way to go, when you > have more methods it gets cumbersome.. But the XML-RPC request needs to return data, while the browser request needs to return the data formatted meaningfully for a user to view. You'll have to write some extra code anyway to format the output for the browser, so I don't see why it's much more cumbersome to use separate servlets. > > Or there may be some clever way to get one class to be able to respond to > > either XMLRPC or regular browser requests. I'll think about it. > > yeah, that's what I was thinking about too. Propably you > have code for something like > > class XMLRPCPage(HTTPServlet): > > before I start my night session today :-) > The class should have the funtionality of Page and XMLRPCServlet, > which unfortunately have both HTTPServlet as base class > > class XMLRPCServlet(HTTPServlet): > class Page(HTTPServlet): > > so one needs to factor out some of the XMLRPCServlet Code > into another Mixin class. Exactly. You could put the stuff that's in XMLRPCServlet now into XMLRPCMixin, then write class XMLRPCServlet(HTTPServlet, XMLRPCMixin): for use when you only want XMLRPC, and class XMLRPCPage(Page, XMLRPCMixin): for use when you want both. > I have the feeling that you need extraURLPath > for a class beeing able to respond to either XMLRPC > or regular browser requests. The circle is closing here :-) Yes, you could use the extraURLPath to determine which method to call in the web browsing case. But see my objections below. > B.T.W: How many methods should one expose in such a XMLRPCPage then? > To many of them is not good memorywise I think. comments? I'm still not convinced it's a good idea to just go ahead and serve up the same methods via XML-RPC and via web browsing. First of all, in the web browsing case you have to do extra work to format the data for the user, as I mentioned above (or you could just format the data in some arbitrary way, I suppose, but what use is that?). Second, I think XML-RPC is stateless -- there are no cookies or other state information that can be used to preserve sessions, unless you explicitly add them as parameters in your XML-RPC methods. So there's some incompatibility there. Finally, I see XML-RPC as a way of exposing a lower-level API for your application to be controlled programmatically. You don't _want_ to be exposing that level for the user to see through their browser -- the browsing experience should be prettier and higher-level. So separating the XML-RPC and the web browsing into separate servlets that make use of shared mixin for common functionality seems like the right way to me. Anyone else have any thoughts? -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Chuck E. <ec...@mi...> - 2000-12-15 23:11:10
|
At 04:04 PM 12/15/2000 -0500, Geoff Talvola wrote: >So separating the XML-RPC and the web >browsing into separate servlets that make use of shared mixin for common >functionality seems like the right way to me. > >Anyone else have any thoughts? I think the exact same thing. -Chuck |
From: Tom S. <tom...@li...> - 2000-12-15 23:41:44
|
Geoff Talvola wrote: > > Tom Schwaller wrote: > > > Geoff Talvola wrote: > > > > > > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser > > > requests. If you're willing to do a small amount of extra work, you can get > > > the effect you want, by implementing the function in a mixin class, then > > > creating two servlets that utilize the mixin class. For example (untested): > > > > > > class AdderMixin: > > > def add(self, x, y): > > > return x + y > > > > > > class XMLRPCAdder(XMLRPCServlet, AdderMixin): > > > def exposedMethods(self): > > > return ['add'] > > > > > > class HTMLAdder(Page, AdderMixin): > > > def writeBody(self): > > > req = self.request() > > > try: > > > x = int(req.field('x')) > > > y = int(req.field('y')) > > > except: > > > self.writeln('Your input was bad') > > > else: > > > self.writeln('The answer is <B>%d</B>' % (self.add(x, y))) > > > > For a reduced API this is certainly the way to go, when you > > have more methods it gets cumbersome.. > > But the XML-RPC request needs to return data, while the browser request needs to > return the data formatted meaningfully for a user to view. You'll have to write > some extra code anyway to format the output for the browser, so I don't see why > it's much more cumbersome to use separate servlets. > > > > Or there may be some clever way to get one class to be able to respond to > > > either XMLRPC or regular browser requests. I'll think about it. > > > > yeah, that's what I was thinking about too. Propably you > > have code for something like > > > > class XMLRPCPage(HTTPServlet): > > > > before I start my night session today :-) > > The class should have the funtionality of Page and XMLRPCServlet, > > which unfortunately have both HTTPServlet as base class > > > > class XMLRPCServlet(HTTPServlet): > > class Page(HTTPServlet): > > > > so one needs to factor out some of the XMLRPCServlet Code > > into another Mixin class. > > Exactly. You could put the stuff that's in XMLRPCServlet now into XMLRPCMixin, > then write > > class XMLRPCServlet(HTTPServlet, XMLRPCMixin): > > for use when you only want XMLRPC, and > > class XMLRPCPage(Page, XMLRPCMixin): > > for use when you want both. > > > I have the feeling that you need extraURLPath > > for a class beeing able to respond to either XMLRPC > > or regular browser requests. The circle is closing here :-) > > Yes, you could use the extraURLPath to determine which method to call in the web > browsing case. But see my objections below. > > > B.T.W: How many methods should one expose in such a XMLRPCPage then? > > To many of them is not good memorywise I think. comments? > > I'm still not convinced it's a good idea to just go ahead and serve up the same > methods via XML-RPC and via web browsing. First of all, in the web browsing case > you have to do extra work to format the data for the user, as I mentioned above > (or you could just format the data in some arbitrary way, I suppose, but what use > is that?). Second, I think XML-RPC is stateless -- there are no cookies or other > state information that can be used to preserve sessions, unless you explicitly add > them as parameters in your XML-RPC methods. So there's some incompatibility > there. Finally, I see XML-RPC as a way of exposing a lower-level API for your > application to be controlled programmatically. You don't _want_ to be exposing > that level for the user to see through their browser -- the browsing experience > should be prettier and higher-level. So separating the XML-RPC and the web > browsing into separate servlets that make use of shared mixin for common > functionality seems like the right way to me. Somehow I viewed Zope as a model here, but I completely agree with the above statement. With Zope you get everything (in this case XML-RPC) for free, but you pay performancewise for the overhead, which in most cases you just don't need (I always wrote spezial Zope-Methods to be used by XML-RPC, but you can call all other methods by XML-RPC too, which gives no sense in most of the cases, because you get plain (useless) HTML..). > Anyone else have any thoughts? -- Tom Schwaller http://www.linux-community.de |
From: Geoff T. <gta...@na...> - 2001-02-02 19:42:34
|
Fixed a bug in COMKit that was caused by the new Properties.py stuff. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2001-02-02 20:27:56
|
Fixed a bug in ModPythonAdapter.py -- it was prepending two newlines to the content, which is OK for HTML, but was causing binary files such as images to break. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2001-02-02 22:33:24
|
Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets. (Although it might not be such a great idea to rely on __del__ in a Servlet.) -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Terrel S. <tsh...@tr...> - 2001-02-02 23:41:23
|
Geoff Talvola wrote: > Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets. (Although it might not be such a great idea to rely on __del__ in a Servlet.) Now I am really confused. Which is it supposed to be? Is transaction.response().rawResponse() supposed to be a string or a dictionary? Oh well. It seems to be working now. Sorry, Jay, about the bad bugfix. |
From: Geoff T. <gta...@na...> - 2001-02-02 23:47:41
|
Terrel Shumway wrote: > Geoff Talvola wrote: > > > Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets. (Although it might not be such a great idea to rely on __del__ in a Servlet.) > > Now I am really confused. Which is it supposed to be? Is > transaction.response().rawResponse() supposed to be a string or a dictionary? > > Oh well. It seems to be working now. Sorry, Jay, about the bad bugfix. It looks like OneShotAdapter was modified assuming that rawResponse() returned a string, but rawResponse hasn't been modified yet, so I had to revert OneShotAdapter's response code back to the way it was before, where it expects a dictionary. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Jay L. <js...@js...> - 2001-02-02 23:59:59
|
Your fix was fine. It returns a string. For now. ;) Jay Terrel Shumway wrote: > Geoff Talvola wrote: > >> Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets. (Although it might not be such a great idea to rely on __del__ in a Servlet.) > > > Now I am really confused. Which is it supposed to be? Is > transaction.response().rawResponse() supposed to be a string or a dictionary? > > Oh well. It seems to be working now. Sorry, Jay, about the bad bugfix. > > > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Jay L. <js...@js...> - 2001-02-03 00:03:04
|
Sorry, I misspoke. The confusion is that OneShot is doing thimngs differently than normal adapters. In the ModPythonAdapter, you are getting back a string, but one shot is conected directly to the appserver, and isn'tr calling Adapter.TransactWithAppServer, it's calling response.rawResponse(), which returns a dictionary. I broke OneShot by forgetting this. Jay Terrel Shumway wrote: > Geoff Talvola wrote: > >> Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets. (Although it might not be such a great idea to rely on __del__ in a Servlet.) > > > Now I am really confused. Which is it supposed to be? Is > transaction.response().rawResponse() supposed to be a string or a dictionary? > > Oh well. It seems to be working now. Sorry, Jay, about the bad bugfix. > > > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Geoff T. <gta...@na...> - 2001-02-02 22:50:03
|
This is absolutely, positively, the last CVS update message you'll get from me today. I fixed the truncated response problem using ThreadedAppServer. As far as I can tell, the tip of CVS now works perfectly. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Jay L. <js...@js...> - 2001-02-02 23:49:12
|
Thanks, that one was hiding. I added one more fix in ModPythonAdapter. Also, FCGIAdapter should work now, while it might not have before. Jay Geoff Talvola wrote: > This is absolutely, positively, the last CVS update message you'll get from me today. > > I fixed the truncated response problem using ThreadedAppServer. As far as I can tell, the tip of CVS now works perfectly. > > -- > > > - Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss |