From: Paul D. F. <pdf...@ku...> - 2005-10-15 05:13:42
|
I'm trying to package (jar) an application which uses dbexts to load a postgresql driver from a ini file. Example ini file: [default] name=postgresql [jdbc] name=postgresql url=jdbc:postgresql:cynefin user=xyz pwd=foo driver=org.postgresql.Driver datahandler=com.ziclix.python.sql.handler.PostgresqlDataHandler Everything is going along fine in the packaged (jar'ed) application until dbexts tries to use the database. Then I get this error: Lib/dbexts.py", line 0, in __init__ ImportError: No module named handler This is the command line I use to run the demo -- under Linux: java -classpath postgresql-8.0-312.jdbc3.jar:jython.jar:demo.jar tests or Windows: java -classpath postgresql-8.0-312.jdbc3.jar;jython.jar;demo.jar tests where tests is a python module tests.py running some tests. As I said, that basic part works (under either). The jython.jar file is one I made as a developer build from CVS, but I do not especially think that is the problem. In fact, I only include it there, despite doing a build all, because somehow if I don't I get a: ImportError: cannot import name zxJDBC so something in the --all isn't getting into my demo.jar file perhaps? (Obviously I need jython.jar without the --all build). I think what is going wrong here is that somehow that this one dynamically loaded class is not found in its jar file because something about the packaging was done wrong (by me, or the packager?) When I make a --bean, everything works OK when I have a copy of the jython Lib directory tree in the application directory. Presumably the dbexts class is dynamically loading things better then. I guess I can live with that, but I'd rather have all the python support files in the jar file. It is when I try to use --all to package things that I get this problem, almost like it is not looking into the postgresql jar file. When packaging, I get com.ziclix.python.sql as a required Java package, but not the longer com.ziclix.python.sql.handler. I even tried adding a "-A org.python.modules,org.apache.oro.text.regex,com.ziclix.python.sql.handler" to the command line, as in (becuase I am using a custom built jython from CVS), for example: java -jar jython_distribution/jython.jar -Dpython.path=./jython_distribution/Lib/ jython_distribution/Tools/jythonc/jythonc.py --all -A org.python.modules,org.apache.oro.text.regex,com.ziclix.python.sql.handler --jar demo.jar *.py But it still doesn't work. And in any case, it seems having to specify the class when packaging would defeat the purpose of using an INI file to specify the database driver. (But I may not understand that option). I can probably hardcode the database into the file and packagae for only that one driver, but I'm trying to keep the system flexible (the whole point of dbexts). Or I can go with --bean and including the Lib directory. Anyway, I'd still like to make the complete jar file work. Any ideas on what I am missing here? --Paul Fernhout |
From: Paul D. F. <pdf...@ku...> - 2005-10-20 01:50:39
|
Paul D. Fernhout wrote: > I'm trying to package (jar) an application which uses dbexts to load a > postgresql driver from a ini file. Just a follow up to this. I never solved the postgresql problem as nicely as I would have likes, but I did solve it. My work around was to force import of postgresql handler for packaging using: import com.ziclix.python.sql.handler.PostgresqlDataHandler I guess somehow jythonc just does not put this into the application jar file since it is not referenced except at runtime? Is this a bug in jythonc or perhaps the ziclix related configuration? This surprises me since ziclix is essentially part of the jython distribution, and this did not work even when I tried the -all option. It is not a big deal to import any needed handler (assuming they won't fail on import without a related driver jar file in the classpath?) but it seems like this should not be needed for included functionality like dbexts. As another packaging issue, I also found that I needed to have the xerces.jar file in the classpath when I ran jythonc in order to produce an "demo.jar" file which could load xerces (xml handling) at runtime. I also used the -A option for that one, to complement the import in the code of: import org.apache.xerces.parsers.SAXParser But even with the -A option set, without that xerces.jar in the jythonc class path at compile time, the application would not load xerces.jar at runtime. I would think -A would be enough by itself? And why should it even be needed since the import is clearly in the application code (as opposed to being synthesized at run time from strings)? I remain surprised that there were no obvious warnings on these sorts of situations. Still, by looking at the output I can see that jythonc (when it did not work) did not include the various items as needed in its "Tracking java dependencies:" and "Required packages:" output sections. But you have to know what to look for (or rather, look for to be missing, after getting the runtime error message). Since I had that other error (and workaround) with a double import of some file (javapath), possibly there may be a bug in jythonc, at least in so far as running it with python 2.2 class libraries. Or maybe it is just something I am doing wrong or still don't undesrstand. I am not yet doing anything at runtime with the pythonpath -- perhaps that is part of the problem (I saw some references to loading the java classpath into the pythonpath by the application?) Still, I get the feeling that there is something in the result of jythonc that is short circuiting looking very hard for stuff in the java classpath, since the results work when using a plain jython.jar file and the Lib files. I assume that jythonc needed access to this xerces jar file in the classpath to build the interface? I found I can load classes from jar files dynamically even with a jythonc'd application, so I am surprised at something loaded at run-time being required to be in the classpath at compile time to make the later runtime import work. Again, I get the feeling jythonc is doing something that makes it harder for application code at runtime to load classes from the java classpath. Might still be something quirky about what I am doing though, or my still evolving understanding of this process. But in any case, I got it to work well enough for the current needs. And Jython sure is impressive when everything comes together! For reference, here is the command line that worked for me to package something with postgresql and xerces using a custom jython.jar file built from CVS (and using related libraries (derived partially from the python 2.2 distribution): java -cp xerces-1.4.4.jar:jython_distribution/jython.jar org.python.util.jython -Dpython.path=./jython_distribution/Lib/ jython_distribution/Tools/jythonc/jythonc.py -A org.apache.xerces.parsers --jar demo.jar *.py Also for reference, the command line to run the result under GNU/Linux (Windows needs ';' instead of ':' in the classpath): java -classpath xerces-1.4.4.jar:postgresql-8.0-312.jdbc3.jar:jython.jar:demo.jar tests (where "tests" is a jython module I want to run, which has the previously mentioned import statements). --Paul Fernhout |