Actually, there is a very sensible error in the error.log file. You just have to look for the lines that say "exception" or "error", like so:
On Tue, Aug 17, 2010 at 11:07 PM, James Durham <[email protected]>wrote: > [Tue Aug 17 22:03:04 2010] [error] /usr/local/turbogears/BASELINE/lib/ > python2.5/site-packages/SQLAlchemy-0.5.1-py2.5.egg/sqlalchemy/engine/ > default.py:229: SAWarning: Unicode type received non-unicode bind > param value 'editor' > [Tue Aug 17 22:03:04 2010] [error] param.append(processors[key] > (compiled_params[key])) > [Tue Aug 17 22:03:04 2010] [error] /usr/local/turbogears/BASELINE/lib/ > python2.5/site-packages/SQLAlchemy-0.5.1-py2.5.egg/sqlalchemy/engine/ > default.py:229: SAWarning: Unicode type received non-unicode bind > param value 'editor' > [Tue Aug 17 22:03:04 2010] [error] param.append(processors[key] > (compiled_params[key])) > [Tue Aug 17 22:03:05 2010] [error] [client 127.0.0.1] Error - <type > 'exceptions.AttributeError'>: 'module' object has no attribute 'dumps' > Look at that last line, and that's the core of your problem:Some module object, somewhere in the code, is looking for an attribute "dumps", not finding it, and bailing out. Now, considering that, considering that Paster works while mod_wsgi does not, I've just checked out all of the tg2.0.3 source tree, along with a quickstarted app. "dumps" is only mentioned in one place in all of that, and that's one of the test cases provided by TG itself. It wouldn't be causing your current failure. Digging further up the relevant lines above, we see SQLAlchemy producing errors. When I grep through SQLAlchemy's installed egg, I find several instances of "dumps" being used, which leads me to believe that all of your errors are coming down to issues with SQLAlchemy on your machine. Further deduction: Since Paster works, and mod_wsgi does not, the logical thing to do is to validate that mod_wsgi is actually getting your virtualenv correctly, *and* that your virtualenv is actually set up correctly. To verify that, we need to know the following: 1. The *exact* command you used to make your virtualenv 2. The *exact* contents of your Apache configuration for the site 3. The *exact* contents of the .wsgi script which is being run by mod_wsgi 4. The *exact* path in which your virtualenv exists 5. The *exact* path that contains your production.ini file The *only* things you should obscure would be passwords, usernames, and (maybe) machine names. Once we have that, we can debug what's going on with mod_wsgi, and understand what's wrong in our documentation that allowed this problem to occur, so we can fix that. -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
