Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2007-01-16 02:37:44 →
Size: 1174
Editor: sglanger
Comment:
← Revision 4 as of 2007-01-16 02:39:15 → ⇥
Size: 1172
Editor: sglanger
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
 During Oct-Nov 2006 there was a thread in the jython-users group titled "adding Jars to sys.path". More accurately the objective there was to add Jars to the sys.path at runtime. Several people asked the question, "Why would you want to do that?" Well there are at least 2 good reasons. First, if you want to distribute a jython or Java package that includes non-standard Jars in it, perhaps you want to make life easier for the target user and deamnd that they know how to set environment variables. A second even more compelling reason is when there ''is no normal user account to provide environment variables'''. "What?", you ask? Well, in my case I came upon it in the following way. I am authoring an Open Source IHE Image Archive Actor [1] and needed a web interface and am using AJAX on the client side to route database calls through CGI to a jython-JDBC enabled API. Testing the jython-JDBC API from the command line worked fine, I had the PostGres driver in my CLASSPATH. But, when called via the web interface - no luck. Why? Because APACHE was calling the API and APACHE is not a normal account with environment variables.  During Oct-Nov 2006 there was a thread in the jython-users group titled "adding Jars to sys.path". More accurately the objective there was to add Jars to the sys.path at runtime. Several people asked the question, "Why would you want to do that?" Well there are at least 2 good reasons. First, if you want to distribute a jython or Java package that includes non-standard Jars in it, perhaps you want to make life easier for the target user and deamnd that they know how to set environment variables. A second even more compelling reason is when there ''is no normal user account to provide environment variables'''. What?, you ask? Well, in my case I came upon it in the following way. I am authoring an Open Source IHE Image Archive Actor [1] and needed a web interface and am using AJAX on the client side to route database calls through CGI to a jython-JDBC enabled API. Testing the jython-JDBC API from the command line worked fine, I had the PostGres driver in my CLASSPATH. But, when called via the web interface - no luck. Why? Because APACHE was calling the API and APACHE is not a normal account with environment variables.

Introduction

  • During Oct-Nov 2006 there was a thread in the jython-users group titled "adding Jars to sys.path". More accurately the objective there was to add Jars to the sys.path at runtime. Several people asked the question, "Why would you want to do that?" Well there are at least 2 good reasons. First, if you want to distribute a jython or Java package that includes non-standard Jars in it, perhaps you want to make life easier for the target user and deamnd that they know how to set environment variables. A second even more compelling reason is when there is no normal user account to provide environment variables. What?, you ask? Well, in my case I came upon it in the following way. I am authoring an Open Source IHE Image Archive Actor [1] and needed a web interface and am using AJAX on the client side to route database calls through CGI to a jython-JDBC enabled API. Testing the jython-JDBC API from the command line worked fine, I had the PostGres driver in my CLASSPATH. But, when called via the web interface - no luck. Why? Because APACHE was calling the API and APACHE is not a normal account with environment variables.

What to do?

JythonMonthly/Articles/January2007/3 (last edited 2009-04-10 10:28:36 by AndrewKuchling)