Actually the beauty of this is that you have freedom to have different
apps use different versions of jar files such as jt400.jar, poi, etc and
they don't stomp on each other.
I liken it to .Net applications installing stuff globally or in the app
directory. I tend to go with installing runtime files in the app
directory so I know exactly where everything is running from.
Directories are bigger, but much more controlled.
Most of our stuff is written by us, but we obviously use other jar APIs
as well for java stuff and .Net APIs for .Net stuff.
Regards,
Richard Schoen
RJS Software Systems Inc.
"Get the information you need. Now!"
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 7
date: Tue, 23 Mar 2010 00:52:17 -0500
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: Scott's Excel stuff and Giovanni's XLPARSE2
Yes, that's exactly the scenario I was talking about. If someone had
the same JAR files you were using, but in a different version, and
placed them in /QIBM/UserData/Java400/ext, your application wouldn't
work.
(Of course, I suspect the JARs you distribute are probably all written
by RJS, so probably not too many conflicts in your case...)
Richard Schoen wrote:
We have created our own directory structure to store JAR files.
Ex: /RJSJAVA/APPNAME
Then we set the job classpath as needed to access the appropriate
files.
This has proven to work quite well to keep things from getting sticky.
midrange.com
