|
Thanks Barbara, that looks like the best way to approach it.
I'm wondering though why initial environment values can't be set with a job
description, in the same way as library lists.
Is that due to the usual reason (ie only 24 hours in a working day) or has
the job description design fallen out of favour?
Regards,
John
|---------+------------------------------>
| | Barbara Morris |
| | <bmorris@xxxxxxxxxx|
| | > |
| | Sent by: |
| | java400-l-bounces@m|
| | idrange.com |
| | |
| | |
| | 09/11/2004 02:29 PM|
| | Please respond to |
| | Java Programming on|
| | and around the |
| | iSeries / AS400 |
| | |
|---------+------------------------------>
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: java400-l@xxxxxxxxxxxx
|
| cc:
|
| Subject: Re: Deploying jar files
|
>--------------------------------------------------------------------------------------------------------------|
jthompson@xxxxxxxxxxx wrote:
> ...
> I guess I should outline what I'm currently doing:
> - any RPG program that wants to use Java classes calls a procedure
> 'setClassPath' which sets the environment value CLASSPATH. This is good
> because it means the classpath is set differently for developers and all
> other users (the code within setClassPath is able to determine whethwer
> it's a development or production environment). But it's also bad because
1)
> once the JVM is started, all subsequent calls to setClassPath are
> ineffective 2) developers aren't always remembering to code the call 3)
> everytime I want to evaluate a new Java extension it means code changes
and
> re-compilations.
>
If developers know who they are, and possibly already call something to
setup the development environment, then you could have *SYS level
environment variable that sets up CLASSPATH for all-other-users, and
developers could call some startup CL program that replaces that job's
*JOB CLASSPATH envvar with the development version of the classpath. If
the set-dev-envvar program wasn't called, the job would default to the
all-other-users envvar.
When you need to change the classpath, you have only two places to do
it: the *SYS envvar and the program that sets the *JOB envvar.
I would stay away from calling setClassPath from every program. It will
become less and less reliable as more of your RPG programs use Java, for
all three reasons you state.
--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.