Issue 64 in django-jython: Problem with Websphere Application Server 6.1
django...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 64 by arr...@gmail.com: Problem with Websphere Application Server
6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Hello,
I am trying to use Django 1.3 (django-jython-1.3.0b1) on Websphere
Application Server 6.1. I have created simple application which contains
only django admin. I have deployed it on server but when I try to get admin
page I receive error 500 and stack trace in log:
[14.06.11 11:12:35:274 CEST] 00000024 LocalTranCoor E WLTC0017E: Resources
rolled back due to setRollbackOnly() being called.
[14.06.11 11:12:35:281 CEST] 00000024 WebApp E [Servlet Error]-[modjy]:
Traceback (most recent call last):
File "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py",
line
80, in service
self.exc_handler.handle(req, resp, wsgi_environ, mx, (typ, value, tb) )
File "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py",
line
76, in service
self.dispatch_to_application(req, resp, wsgi_environ)
File "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py",
line
103, in dispatch_to_application
self.raise_exc(ApplicationException, str(x))
File "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py",
line
121, in raise_exc
raise exc_class(message)
modjy.modjy_exceptions.ApplicationException: Caught AttributeError while
rendering: 'NoneType' object has no attribute 'endswith'
at org.python.core.PyException.doRaise(PyException.java:200)
at org.python.core.Py.makeException(Py.java:1225)
at
modjy.modjy_exceptions$py.handle$23(/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy_exceptions.py:91)
at
modjy.modjy_exceptions$py.call_function(/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy_exceptions.py)
at org.python.core.PyTableCode.call(PyTableCode.java:165)
at org.python.core.PyBaseCode.call(PyBaseCode.java:301)
at org.python.core.PyBaseCode.call(PyBaseCode.java:194)
at org.python.core.PyFunction.__call__(PyFunction.java:387)
at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:220)
at org.python.core.PyMethod.__call__(PyMethod.java:211)
at org.python.core.PyMethod.__call__(PyMethod.java:201)
at
modjy.modjy$py.service$7(/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py:80)
at
modjy.modjy$py.call_function(/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/laptopNode01Cell/pollsite_war.ear/pollsite.war/WEB-INF/lib-python/Lib/modjy/modjy.py)
at org.python.core.PyTableCode.call(PyTableCode.java:165)
at org.python.core.PyBaseCode.call(PyBaseCode.java:301)
at org.python.core.PyBaseCode.call(PyBaseCode.java:194)
at org.python.core.PyFunction.__call__(PyFunction.java:387)
at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:220)
at org.python.core.PyMethod.__call__(PyMethod.java:211)
at org.python.core.PyMethod.__call__(PyMethod.java:201)
at org.python.core.PyMethod.__call__(PyMethod.java:196)
at org.python.core.PyObject._jcallexc(PyObject.java:3502)
at org.python.proxies.modjy.modjy$modjy_servlet$0.service(Unknown Source)
at com.xhaus.modjy.ModjyJServlet.service(ModjyJServlet.java:139)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
(below are websphere classes)
I probably misconfigured something. Can someone give me a clue what I have
done wrong?
django...@googlecode.com
Owner: juneau001
Comment #1 on issue 64 by juneau001: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Sorry you are having troubles. Can you please state the database that you
are using? Looks like the issue may be database-specific. The exception
indicates to me that there may be some underlying SQL that is not being
processed correctly by Django.
django...@googlecode.com
Comment #3 on issue 64 by hindtyres: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Attachments:
desktop.ini 282 bytes
django...@googlecode.com
Comment #2 on issue 64 by hindtyres: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Attachments:
desktop.ini 282 bytes
django...@googlecode.com
Comment #4 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I am using postgresql 9.0.3 with postgresql-9.0-801.jdbc3.jar (jar included
in war with application).
I have tested this war on Websphere Application Server Community Edition
2.1.1.5 which is based on Apache Geronimo 2.1.7 and it works "out of the
box".
So I think the problem is with WAS configuration.
I debug it and exception is thrown form (modjy.py:96):
app_return = self.call_application(app_callable, environ, response_c
allable)
I'll try to test it on WAS 7.0.
django...@googlecode.com
Comment #5 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I tried to launch application on WAS 7.0 but this problem still exists.
I debug it a little and get exception which might gives mode information:
django.template.TemplateSyntaxError: Caught AttributeError while
django...@googlecode.com
Comment #6 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I have found what is the real cause of this exception, sys.prefix is None.
For this moment I do not know how to solve this problem but this problem.
django...@googlecode.com
Status: Started
Comment #7 on issue 64 by juneau001: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Thanks for your time in debugging the issue. Maybe there is something that
can be caught in modjy to eliminate this issue. I've dug into the modjy
code briefly, but I am unfamiliar in that area.
Can you please show what you are using for the configuration in
settings.py? That may help us debug the issue.
Thanks
django...@googlecode.com
Comment #8 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I'm more interested in seeing your web.xml, to see what modjy context and
servlet parameter values you're using.
The exception handling on modjy needs cleaning up: it hides too much
information and misleads users.
django...@googlecode.com
Comment #9 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
It's also worth noting that websphere can be problematic because it
includes jython 2.1, including the 2.1 jython.jar in its system libraries.
This can mean that the wrong jython can get picked up at initialisation.
The solution to this problem is to modify the classloader configuration,
inverting the class loading path to load application jars *before* system
jars: I forget the configuration option that does this.
I'm tempted to out some 2.5 syntax into modjy, to ensure that the user gets
a syntax error immediately if they end up getting the system jython 2.1
instead of the jython 2.5 jar that they properly placed in WEB-INF/lib
I did some playing with websphere before, and succeeded in getting it
working by modifying the classloader configuration. But it gave capricious
behaviour, in that it worked sometimes and would then stop after a
container restart, without any configuration changes.
Websphere is excessively complex and flaky: I don't know why some companies
are so enamoured with it. There are far more robust containers, e.g.
glassfish, jboss, jetty, tomcat, etc, etc.
django...@googlecode.com
Comment #10 on issue 64 by juneau001: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
Alan,
That makes sense. Wish I was more familiar with all things modjy. So the
solution to this problem is to modify the classloader configuration. Is
there anything else that we can do within django-jython for this issue? If
so, we should make you the owner of this issue since I'm a modjy novice (if
that). :)
django...@googlecode.com
Comment #11 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I have switched application classloader to "parent last" but it haven't
solved the problem. Can you tell me how I should modify application to
check which jython library was loaded? I do not trust WAS. ;-)
Exception is thrown from gettext module, from line:
_default_localedir = os.path.join(sys.prefix, 'share', 'locale')
sys.prefix is None but function join from posixpath tries to invoke method
endswith('/') on it. As far as I know gettext is standard python module and
I have no idea how to change modjy to solve this problem. Of course besides
of setting sys.prefix, but I think this is not a good idea. Do you know how
jython sets sys.prefix? I could not find python sys module so it is
probably built-in module. I would like to check if the problem is with
jython or with WAS.
Settings.py and web.xml are in attachments. If there is something wrong
with either please let me know.
Thank you for replies.
Attachments:
web.xml 1.3 KB
settings.py 3.5 KB
django...@googlecode.com
Comment #12 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
Reading this thread in more detail.
I see that the root of your problem is that sys.prefix is None. Please read
the following documentation on what sys.prefix means.
http://wiki.python.org/jython/UserGuide#finding-the-registry-file
As you can see, there are three ways that the root directorty can be found.
1. The value of the "python.home" setting.
- Looking at your web.xml, I see that you are *not* setting this value.
This might be the simplest way to solve your problem. See here for how to
set this value
http://opensource.xhaus.com/projects/modjy/wiki/ModjyConfiguration
2. The value of the "install.root" setting.
- Probably doesn't exist in this case
3. By finding the path to the jython.jar from which the jython runtime was
loaded.
- Since the other two methods have failed, this where you have ended up.
- There are two possible reasons why jython has failed to find this path
1. Because the servlet is prevented, for either architectural or security
reasons, from discovering this path.
2. Because there is special coding in websphere for jython.jar, because
websphere includes jython 2.1
I recommend that you try setting python.home in your web.xml.
Another possibility to try and discover what is happening is to cut the
modjy java servlet down to a minimum that works, and see what version of
the language is being loaded, etc.
I should also point out: from your traceback posted in the opening message
for this thread, it is failing when calling the "service" method is called,
i.e. when it processing an actual web request. What this tells us that the
initialisation of both jython and modjy has actually succeeded, and failure
comes when it tries to process a request.
The failure relates to a None value in sys.prefix. But modjy never directly
references sys.prefix. Although I imagine that it is quite likely that
Django is relying on the value of sys.prefix, given all of its settings.py
magic.
I recommend making sure that there is a value in sys.prefix. If you can't
achieve setting it by configuration in web.xml, then simply try hardcoding
a value for it, even "", in either modjy source code or settings.py. So put
a statement like this in the execution chain as early as possible
import sys
sys.prefix = "" # "/path/to/jython"
Let us know how that goes.
django...@googlecode.com
Comment #13 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
Some notes for myself and for the django-jython maintainers
1. This problem seems to be caused by a None setting in sys.prefix
2. I am considering putting an explicit check for sys.prefix into modjy, to
ensure that a value is actualy set.
3. It might be worth putting a similar check into django-jython. Given all
of Django's magic, it is quite possible that Django cannot currently
operate correctly without a value in sys.prefix. There are two solutions to
this problem
A: Fix Django so that it can operate without a value in sys.prefix. After
all, finding the home directory of a jython installation is *not*
guaranteed in the context of java servlets.
B: Put an explicit check into Django-jython to ensure that a value for
sys.prefix is set. If no value is set, either give the user a warning, or
halt processing and refuse to continue.
django...@googlecode.com
Comment #14 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
Hello and thanks for help. :-)
When I set python.home in web.xml application have started working.
I know that modjy does not reference to sys.prefix. But as I wrote before
gettext does. What's more gettext uses value of sys.prefix during module
initialization, so when someone only imports gettext application crashes
with exception.
In my opinion "fixing" django is not a good idea. Much better way is to
check sys.prefix for None value, but the best way is to add python.home
parameter to web.xml during creation of this file.
I would like to once more thank for help.
Cheers
django...@googlecode.com
Comment #15 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
Glad that that worked for you.
Since you have a running Websphere installation, please can I ask you to
check something?
Is it necessary to change the classloader hierarchy in order for jython 2.5
and modjy to work?
Or does the classloader hierarchy make no difference?
I want to put together a specific set of notes for modjy users who want to
use websphere, and want to cover all of the things that they might need to
know.
Whatever you find, is that true for both WAS 6.1 and WAS 7?
django...@googlecode.com
Comment #16 on issue 64 by alan.ken...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
I have added a description of this problem and its solution to the Modjy
TroubleShooting page
http://opensource.xhaus.com/projects/modjy/wiki/ModjyTroubleShooting
django...@googlecode.com
Comment #17 on issue 64 by arr...@gmail.com: Problem with Websphere
http://code.google.com/p/django-jython/issues/detail?id=64
Everything works fine despite of class loader order. I have tested it on a
WAS 7 (to be more specific 7.0.0.17) but I think it will also work for WAS
6.1. Unfortunately I have uninstalled WAS 6.1 because of disk space
shortage.
If you think the test is necessary I can install 6.1 version and run test.
django...@googlecode.com
Status: Done
Comment #18 on issue 64 by juneau001: Problem with Websphere Application
Server 6.1
http://code.google.com/p/django-jython/issues/detail?id=64
I am closing this issue out because Alan addressed it :
http://opensource.xhaus.com/projects/modjy/wiki/ModjyTroubleShooting
Thanks Alan