[Web-SIG] ANN: Release 0.20.0 of modjy: a WSGI gateway for jython
2.1 and J2EE.
py-web-sig at xhaus.com
Mon Oct 4 01:00:20 CEST 2004
[Phillip J. Eby]
> Looks pretty good. FYI, as far as I can tell, your 'j2ee.*' extensions
> aren't compliant, because they can bypass middleware modifications to
> the environment.
Indeed, I was aware of that. I meant to add something to the
documentation which said "these modjy-specific extensions are not
compliant with the strict wording of the spec, which forbids access to
HTTP request and response data in a way that bypasses WSGI mechanisms".
> (I wonder if perhaps the current mechanism to prevent middleware
> bypassing is too heavyweight?)
I'm sort of thinking that it is a little heavyweight. I think that
anyone who wants to bypass the middleware will probably have a good
reason for doing so. Also, they would probably be very aware that their
application would no longer be portable.
Also, I would have to add a fair amount of extra code, just to ensure
that the extension APIs present the same information as the standard
WSGI interface. Which seems unnecessary, given that the WSGI information
is already there.
More importantly, that extra code would then make it impossible for the
application/framework author to get at the original request, which they
might conceivably really, really, need .....
But I am concerned about the statement in the PEP which says "it is very
important that these "safe extension" rules be followed by both
server/gateway and middleware developers, in order to avoid a future in
which middleware developers are forced to delete any and all extension
APIs from environ to ensure that their mediation isn't being bypassed by
applications using those extensions!"
I definitely don't want to bring such a future about ....
> I haven't had time to read all of the source code yet, so I'm not sure
> if that's the only compliance issue, but that's the only one I've seen
> in your documentation.
I am reasonably sure that there are other minor nits in the code, which
I will incrementally fix in the coming weeks.
The reason for "releasing early, releasing often" is that I want to
demonstrate that I am serious about publishing a production-quality
J2EE->WSGI gateway for jython.
> By the way, if you do implement pooling of application objects to bypass
> their single-threadedness, I think the only really safe way to do that
> is by having a separate Jython interpreter for each one. A
> single-threaded application is going to assume it can use module-level
> globals without conflicts, so just creating duplicate application
> objects isn't going to resolve that issue.
That's true, and would indeed be quite messy to implement. I'll leave
that one on the back burner for now.
More information about the Web-SIG