On Fri, Feb 27, 2009 at 11:46 AM, Michael Repucci <mich...@repucci.org>wrote:
> > I've been trying to put my site up live, and keep coming across an > error (on any page on the site) whenever I set debug=False in > settings.py. With the development server, or with debug=True on the > production server, I don't have this problem at all. I searched for a > similar problem on djangoproject and here, and found only a closed > ticket (http://code.djangoproject.com/ticket/8569) with a changeset > (http://code.djangoproject.com/changeset/8605) that I assume was built > into the version I'm using (1.0.2-final). I downloaded the changeset > anyway, and substituted it, but it didn't help. Below is my mod_python > traceback. Any help would be GREATLY appreciated! Thanks!! > That changeset was before 1.0, so yes you should have already had it. You seem to have found a different path to the same ultimate error situation. > MOD_PYTHON ERROR > > ProcessId: 1564 > Interpreter: 'poseidon.sunyopt.edu' > > ServerName: 'poseidon.sunyopt.edu' > DocumentRoot: 'C:/websites/wwwroot' > > URI: '/backuslab/' > Location: '/backuslab/' > Directory: None > Filename: 'C:/websites/wwwroot/BackusLab/' > PathInfo: '' > > Phase: 'PythonHandler' > Handler: 'django.core.handlers.modpython' > > Traceback (most recent call last): > > File "C:\Program Files\Python\Lib\site-packages\mod_python > \importer.py", line 1537, in HandlerDispatch > default=default_handler, arg=req, silent=hlist.silent) > > File "C:\Program Files\Python\Lib\site-packages\mod_python > \importer.py", line 1229, in _process_target > result = _execute_target(config, req, object, arg) > > File "C:\Program Files\Python\Lib\site-packages\mod_python > \importer.py", line 1128, in _execute_target > result = object(arg) > > File "c:\program files\python\Lib\site-packages\django\core\handlers > \modpython.py", line 228, in handler > return ModPythonHandler()(req) > > File "c:\program files\python\Lib\site-packages\django\core\handlers > \modpython.py", line 201, in __call__ > response = self.get_response(request) > > File "c:\program files\python\Lib\site-packages\django\core\handlers > \base.py", line 128, in get_response > return self.handle_uncaught_exception(request, resolver, exc_info) > This is the first indication of a problem, something raised an exception trying to generate a response. Don't know if it is the same as the exception you are ultimately seeing or if something else went wrong. > > File "c:\program files\python\Lib\site-packages\django\core\handlers > \base.py", line 159, in handle_uncaught_exception > callback, param_dict = resolver.resolve500() > > File "c:\program files\python\Lib\site-packages\django\core > \urlresolvers.py", line 218, in resolve500 > return self._resolve_special('500') > > File "c:\program files\python\Lib\site-packages\django\core > \urlresolvers.py", line 207, in _resolve_special > callback = getattr(self.urlconf_module, 'handler%s' % view_type) > > File "c:\program files\python\Lib\site-packages\django\core > \urlresolvers.py", line 198, in _get_urlconf_module > self._urlconf_module = __import__(self.urlconf_name, {}, {}, ['']) > So here the code that is attempting to handle the uncaught exception goes to load your url configuration as part of figuring what to call to generate the 500 response. > File "c:/websites/django/backuslab\laboratory\urls.py", line 5, in > <module> > admin.autodiscover() > > File "c:\program files\python\Lib\site-packages\django\contrib\admin > \__init__.py", line 40, in autodiscover > __import__("%s.admin" % app) > And that calls admin.autodiscover(), which was also present in the earlier tracebacks. But after that the traceback from #8596 doesn't match well with what we see called here. The #8596 traceback proceeded into validate(), which is only called if DEBUG is True, and that is where the fix was put. In this case you're not going into validate(), but rather are encountering the error just on defining a ModelForm. > > File "c:/websites/django/backuslab\laboratory\people\admin.py", line > 107, in <module> > class PersonForm(forms.ModelForm): > > File "c:\program files\python\Lib\site-packages\django\forms > \models.py", line 195, in __new__ > opts.exclude, formfield_callback) > > File "c:\program files\python\Lib\site-packages\django\forms > \models.py", line 162, in fields_for_model > formfield = formfield_callback(f) > > File "c:\program files\python\Lib\site-packages\django\forms > \models.py", line 177, in <lambda> > lambda f: f.formfield()) > > File "c:\program files\python\Lib\site-packages\django\db\models > \fields\related.py", line 914, in formfield > defaults = {'form_class': forms.ModelMultipleChoiceField, > 'queryset': self.rel.to._default_manager.complex_filter > (self.rel.limit_choices_to)} > > AttributeError: 'str' object has no attribute '_default_manager' > Some details of your models and admin.py might help isolate what is going on here. You're apparently going down some path that is assuming apps have been fully loaded when they are not. You are going down this path while the code is attempting to handle a 500 error -- I don't know if the first error is the same (in which case there's likely something in your model/admin defs that seems to be not handled properly, at least when DEBUG is False), or if the first error interrupted/prevented the full loading of models and that's why the subsequent code runs into trouble. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
