Error on start-up
Peter Herndon
I'm new to WSGI programming, and to Aspen, so I suspect my problem
lies in something I'm not doing properly. I've built the initial
skeleton of a REST app using Luke Arno's selector, and I'm trying to
get it to work under Aspen. I'm using __/etc/middleware.conf, where I
have the line
controller:s
In my controller.py file, located in __/lib/python2.5, I instantiated
s as a Selector, and have added several paths to it. At the moment,
the functions just return their own name. When I start Aspen in my
top-level directory, I get the following error:
$ aspen
launching child process
starting child server
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/Current/bin/
aspen", line 3, in <module>
aspen.main()
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages/aspen-0.7-py2.5.egg/aspen/__init__.py", line
338, in main
start_server(configuration)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages/aspen-0.7-py2.5.egg/aspen/__init__.py", line
145, in start_server
server = server_factory(configuration) # factored out to ease
testing
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages/aspen-0.7-py2.5.egg/aspen/__init__.py", line
119, in server_factory
website = middleware(website)
TypeError: __call__() takes exactly 3 arguments (2 given)
Obviously the server startup process is looking for something else in
addition to what I've given it, but what that something might be is
unknown to me. I am using version 0.7, and middleware.conf is the
only configuration file I'm using, and I'm not passing anything to
aspen on the commandline. What am I missing? Am I using Aspen
properly for what I'm trying to do?
Thanks!
iGL
app, right? So, make apps.conf file and configure the basic path
there, like so:
/ mypackage.mymodule:mywsgicallable
The wsgi app put to be served by aspen then can use any router
package. Thus aspen will pick up the right wsgi app and the latter
will pick up the right controller via Selector routing.
middleware.conf mustn't be the *only* configuration file ;)
greetings,
giorgi
Peter Herndon
I'm not yet there.
On Feb 22, 8:24 am, "iGL" <Giorgi.Lekishv...@gmail.com> wrote:
> A quick reply: if you're using middleware, you should be using a wsgi-
> app, right? So, make apps.conf file and configure the basic path
> there, like so:
> / mypackage.mymodule:mywsgicallable
I have created the apps.conf, and the single entry in it is:
/ controller:s
> middleware.conf mustn't be the *only* configuration file ;)
At this point, when I have the above apps.conf in place *and*
middleware.conf in place, I get the same error I posted previously.
However, when I mv middleware.conf out of the way and run Aspen with
just apps.conf, Aspen runs. The problem I run into at this point is
that I get 404s on every request.
Here's an abridged version of my controller.py file -- perhaps I'm
doing something wrong here? It is simple at the moment, as I learn my
way around my new tools.
from selector import Selector
def projects(environ, start_response):
start_response("200 OK", [('Content-type', 'text/plain')])
return ["projects"]
def create_project(environ, start_response):
start_response("200 OK", [('Content-type', 'text/plain')])
return ["create_project"]
s = Selector()
s.prefix = '/gtdapp/'
s.add('/projects[/]', GET=projects)
s.add('/projects[/]', POST=create_project)
And here is the 404 text I receive. I don't know if that's coming
from Aspen or from selector.
404 Not Found
The server has not found anything matching the Request-URI.
Thanks again for the help!
---Peter
iGL
Quick solution:
in your apps conf:
/projects controllers:projects
/create_project controllers:create_project
delete middleware.conf and sellector stuff in controllers.py for the
time being ;)
The reason is that aspen has his built_in routing to the *wsgi* apps.
Selector-like routers should be using *inside* of the wsgi callables.
For example, most of the modern pythonic frameworks are single wsgi
apps. The mechanism roughly is as follows:
- request hits aspen
- aspen finds the corresponding wsgi callable based on *apps.conf*
- the very wsgi callable examines environ['path_info'], calls router
(i.e., routes, selector) and discovers the required page- or action
controller
The middlewares specified in middleware.conf (if any) handle the
things as is specified.
When however, an aspen user is willing to use wsgi callables as
controllers themselves, there's no need to use external routers. Aspen
is smart enaugh to figure out which callable is requested.
Thus we need to see clearly the difference between the wsgi callable
in the role of dispatcher and in the role of controller ;) Much like
in the java world: a servlet can be dispatcher of a framework or
simple controller - tomcat and the like will be using their own
routers based on the configs. If the servlet is dispatcher and not a
controller, it's then a framework developer's responsibility to teach
the dispatcher which controller is expected to be put in action - the
controllers there need not to be servlets.
HTH,
giorgi
iGL
Now I have taken a look over selector package. As I see, a Selector
class instance is a valid wsgi app and thus it can well be a responder
of aspen. Therefore you can safely use it with aspen. Now, my conf
(based on your controllers.py) is as follows:
1)no middleware.conf
2)in apps.conf:
/gtdapp controllers:s
3)in controllers.py:
comment out the prefixing, i,e, s.prefix='/gtdapp/
Now, launch aspen and point your browser to http://localhost:8080/gtdapp/projects
. You would see projects in the browser window.
As it appears, the problem is that aspen and selector do prefixing in
an visibly incompatable manner. I'll try to figure out a remedy
provided the latter is not going to affect functioning of non-selector
stuff. Anyway, everything is already fine; just let aspen be a
mechanism that does prefixing ;)
greetings,
giorgi
Peter Herndon
> 1)no middleware.conf
> 2)in apps.conf:
> /gtdapp controllers:s
> 3)in controllers.py:
> comment out the prefixing, i,e, s.prefix='/gtdapp/
>
> Now, launch aspen and point your browser tohttp://localhost:8080/gtdapp/projects
> . You would see projects in the browser window.
This works perfectly!
>
> As it appears, the problem is that aspen and selector do prefixing in
> an visibly incompatable manner. I'll try to figure out a remedy
> provided the latter is not going to affect functioning of non-selector
> stuff. Anyway, everything is already fine; just let aspen be a
> mechanism that does prefixing ;)
I will indeed. For what it's worth, selector is using regular
expressions under the hood. I haven't looked into it in depth, but
I'd imagine that the selector prefix is being appended to the RE at
some point. Since Aspen is quite capable of handling that portion of
the application, I'm very happy with setting up my URL name spaces
through the Aspen configuration.
Thanks again!
---Peter
Chad Whitacre
> This works perfectly!
> Thanks again!
Can I tell you guys how encouraging it is to see questions being
answered here while I was cramming for PyCon?
Woo-hoo!
chad