Use WSGI instead of CherryPy demo server

[Maximilian Gaß]

openerp-web currently uses the CherryPy demo server. It should use Python's standard for web applications, WSGI, instead. It can be nicely integrated with Apache.

openerp/commands.py needs only a few change to be usable as a WSGI application, because CherryPy already supports WSGI.

     cherrypy.config.update({
        'tools.sessions.storage_type': 'file',
        'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
     })

setup_server should return the app object. Then you can return it to the WSGI handler instead of starting the cherrypy.engine

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

I absolutely insist that would be very cool if OpenERP could be WSGI
compliant indeed. Using 5.2 on Jython fro instance, we could then put it on
J2EE robusts servers too, I mean it would open plenty of possibilities. Hope
OpenERP S.A. is keen on making that refactoring.

Raphaël Valyi
http://www.akretion.com

On Wed, Mar 17, 2010 at 10:44 AM, Maximilian Gass <
<email address hidden>> wrote:

> Public bug reported:
>
> openerp-web currently uses the CherryPy demo server. It should use
> Python's standard for web applications, WSGI, instead. It can be nicely
> integrated with Apache.
>
> openerp/commands.py needs only a few change to be usable as a WSGI
> application, because CherryPy already supports WSGI.
>
>
> cherrypy.config.update({
> 'tools.sessions.storage_type': 'file',
> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
> })
>
> setup_server should return the app object. Then you can return it to the
> WSGI handler instead of starting the cherrypy.engine
>
> ** Affects: openobject-client-web
> Importance: Undecided
> Status: New
>
> --
> Use WSGI instead of CherryPy demo server
> https://bugs.launchpad.net/bugs/540255
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Web Client.
>
> Status in OpenObject Web Client: New
>
> Bug description:
> openerp-web currently uses the CherryPy demo server. It should use Python's
> standard for web applications, WSGI, instead. It can be nicely integrated
> with Apache.
>
> openerp/commands.py needs only a few change to be usable as a WSGI
> application, because CherryPy already supports WSGI.
>
>
> cherrypy.config.update({
> 'tools.sessions.storage_type': 'file',
> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
> })
>
> setup_server should return the app object. Then you can return it to the
> WSGI handler instead of starting the cherrypy.engine
>
>
>

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hum, being WSGI compliant would be good both for openerp-server and the
web-client I mean.

2010/3/17 Raphaël Valyi <email address hidden>

> Hello,
>
> I absolutely insist that would be very cool if OpenERP could be WSGI
> compliant indeed. Using 5.2 on Jython fro instance, we could then put it on
> J2EE robusts servers too, I mean it would open plenty of possibilities. Hope
> OpenERP S.A. is keen on making that refactoring.
>
> Raphaël Valyi
> http://www.akretion.com
>
>
> On Wed, Mar 17, 2010 at 10:44 AM, Maximilian Gass <
> <email address hidden>> wrote:
>
>> Public bug reported:
>>
>> openerp-web currently uses the CherryPy demo server. It should use
>> Python's standard for web applications, WSGI, instead. It can be nicely
>> integrated with Apache.
>>
>> openerp/commands.py needs only a few change to be usable as a WSGI
>> application, because CherryPy already supports WSGI.
>>
>>
>> cherrypy.config.update({
>> 'tools.sessions.storage_type': 'file',
>> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
>> })
>>
>> setup_server should return the app object. Then you can return it to the
>> WSGI handler instead of starting the cherrypy.engine
>>
>> ** Affects: openobject-client-web
>> Importance: Undecided
>> Status: New
>>
>> --
>> Use WSGI instead of CherryPy demo server
>> https://bugs.launchpad.net/bugs/540255
>> You received this bug notification because you are a member of OpenERP
>> Drivers, which is subscribed to OpenObject Web Client.
>>
>> Status in OpenObject Web Client: New
>>
>> Bug description:
>> openerp-web currently uses the CherryPy demo server. It should use
>> Python's standard for web applications, WSGI, instead. It can be nicely
>> integrated with Apache.
>>
>> openerp/commands.py needs only a few change to be usable as a WSGI
>> application, because CherryPy already supports WSGI.
>>
>>
>> cherrypy.config.update({
>> 'tools.sessions.storage_type': 'file',
>> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
>> })
>>
>> setup_server should return the app object. Then you can return it to the
>> WSGI handler instead of starting the cherrypy.engine
>>
>>
>>
>

[Xavier (Open ERP) (xmo-deactivatedaccount)]

I completely agree and that's, in fact, on my books.

On the other hand, I don't really get how this:

> cherrypy.config.update({
> 'tools.sessions.storage_type': 'file',
> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
> })

is relevant to running cherrypy as a wsgi framework/container.

[Maximilian Gaß (mxey)]

Xavier, mod_wsgi (for Apache) can run a WSGI application multiple times in multiple threads and/or processes. Currently openerp-web stores its session data in the process memory. If there are multiple processes, the data will not be shared between them. Therefore the session data has to be kept outside a single process, for example in the filesystem.

[Xavier (Open ERP) (xmo-deactivatedaccount)]

On 17 Mar 2010, at 16:29 , Maximilian Gass wrote:
>
> Xavier, mod_wsgi (for Apache) can run a WSGI application multiple times
> in multiple threads and/or processes. Currently openerp-web stores its
> session data in the process memory. If there are multiple processes, the
> data will not be shared between them. Therefore the session data has to
> be kept outside a single process, for example in the filesystem.

Well ok, but that's a deployment issue, session configuration should be moved where it belongs (the config file(s)) and whoever is doing the installation will choose whatever session storage backend fits his/her needs best (whether it's filesystem, database, memcached or RAM), no?
--
Xavier Morel
Developer
OpenERP - OpenERP SA

[Maximilian Gaß (mxey)]

Xavier, you are right. But the configuration should have sensible defaults then.

[Xavier (Open ERP) (xmo-deactivatedaccount)]

Pushed a basic version of the web client as a wsgi app in the web dev branch (note: not trunk, yet). Please try it when it's merged into trunk and feed back.

[Mario César Señoranis (mariocesar)]

I see that a fix was releases, however I don't see any oficial documentation on the website, what is the revision number of the patch? where can I find documentation about this?

[Xavier (Open ERP) (xmo-deactivatedaccount)]

> I see that a fix was releases, however I don't see any oficial documentation on the website, what is the revision number of the patch?

<email address hidden>

> where can I find documentation about this?

There isn't, I'll try to make a pre-built .wsgi launcher with 6.1 after some more internal cleanup.

Currently, we're just using the fact that a CherryPy application (as returned by cherrypy.tree.mount) is also technically a WSGI application, and we expose the root cherrypy application for the web client in `openobject.application`.

You'll have do configure the server yourself (by calling `openobject.configure` at the very least, check `openobject.commands.start` to see the kind of things the complete configuration takes).

Here is a demo session (with the PYTHONPATH correctly set to be able to import openobject) showing how to launch it using wsgiref's simple_server:

    >>> import openobject
    >>> from cherrypy._cpconfig import as_dict
    >>> from wsgiref import simple_server
    >>> openobject.configure(as_dict('doc/openerp-web.cfg'))
    >>> openobject.enable_static_paths()
    >>> httpd = simple_server.make_server('', 8000, openobject.application)
    >>> httpd.serve_forever()

(the enable_static_paths is to serve static files via the cherrypy and thus the WSGI server)

[Xavier (Open ERP) (xmo-deactivatedaccount)]

However, note that Maximilian's warning is correct: I believe there are still issues with the file-based session storage in 6.0, so if you're using a process-based concurrent wsgi server you'll have to use sticky sessions.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Guys any reason you don't make the server layer wsgi compliant too?
On Apr 18, 2011 8:16 AM, "Daniel Watkins (credativ)" <
<email address hidden>> wrote:
> ** Tags added: wsgi
>
> --
> You received this bug notification because you are a member of OpenERP
> Committers, which is subscribed to OpenERP Web Client.
> https://bugs.launchpad.net/bugs/540255
>
> Title:
> Use WSGI instead of CherryPy demo server
>
> Status in OpenERP Web Client:
> Fix Released
>
> Bug description:
> openerp-web currently uses the CherryPy demo server. It should use
> Python's standard for web applications, WSGI, instead. It can be
> nicely integrated with Apache.
>
> openerp/commands.py needs only a few change to be usable as a WSGI
> application, because CherryPy already supports WSGI.
>
>
> cherrypy.config.update({
> 'tools.sessions.storage_type': 'file',
> 'tools.sessions.storage_path': '/var/lib/openerp-web/sessions',
> })
>
> setup_server should return the app object. Then you can return it to
> the WSGI handler instead of starting the cherrypy.engine

[Mario César Señoranis (mariocesar)]

Raphaël Valyi, I think there are many design dependencies on the "one stack" current design, even the web client is hard enough to make it wsgi compliant, as Xavier comment above the sessions are an issue, I even try to rewrite the session handler but seems to tricky ...

Using wsgi, will be a killer feature ! as WSGI enables a lot of solutions for horizontal scaling

I hope the dev team take this more serious

[Maximilian Gaß (mxey)]

Mario, I already described in my first post how you can configure CherryPy to work on WSGI. No need to rewrite the session handler, just configure it to file storage.

This is what we run in production as a WSGI app: https://gist.github.com/925527

[Maximilian Gaß (mxey)]

Also attached it to this comment.