Re: Classpath problems with WAS 3.5

--
[ Picked text/plain from multipart/alternative ]
admin.properties file updates should not be made to
\QIBM\ProdData\WebASAdv\properties\admin.properties file, instead they
should be made to
\QIBM\UserData\WebASAdv\default\properties\admin.properties.

The order that WebSphere uses to search for classes is:
1) app server command line: -classpath
2) \QIBM\UserData\WebASAdv\default\properties\admin.properties (default
instance)
3) webapp classpath

I would recommend using the cmd line arg to set the classpath, especially
since it is searched first.  You should not have to expand jar files for
the classes to be located.  If you are certain authority/configuration is
not a problem, you should run this by IBM.




                      "Ducret, Gilles
                      (CH)"                     To:       "JAVA400-L (E-mail)" 
<JAVA400-L@midrange.com>
                      <Gilles.DUCRET@Llo        cc:       "Thouvenin, Emmanuel 
(CH)" <Emmanuel.THOUVENIN.contractor@LloydsBank.ch>
                      ydsBank.ch>               Subject:  Classpath problems 
with WAS 3.5
                      Sent by:
                      java400-l-admin@mi
                      drange.com


                      11/22/01 09:36 AM
                      Please respond to
                      java400-l





This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Running WAS 3.5.4 on i-series does not satisfy us concerning how WAS is
processing the misc classpath.

We've found 3 ways to set up a classpath :
- 1) in the \QIBM\ProdData\WebASAdv\properties\admin.properties file
- 2) in the app server command line (with the admin console) in the style
of

             -classpath x.jar:y.jar:...:z.jar
- 3) in a webapp classpath style with admin console, advanced tabpane

We still have a lot of problems to understand which is the prefered way to
set it up and and why some classes have to be unpacked from their jar files
in the servlet subdirectory and some other not.
Are we missing something or is it a normal way to do ? in both cases we are
trying to make Cocoon 2 running with WAS 3.5.4 / iseries and it still does
not work because of precedence-problems with system classes (such as
xml4j.jar).

When we change the classpath, and want to resolve the precedence problem
like: put xerces.jar and xalan.jar
before xml4j.jar, it is as if the precedence is not solved (it still takes
the classes from xml4j.jar).

In other cases we must unpack the content of the jar to be able to get the
class.

Can somebody explain why?

Many Thanks

Gilles Ducret
Wealth Management Division
IT Architect
Lloyds TSB Bank
Tel: + 41 22 307 31 50
Mob: +41 79 217 21 41



**********************************************************************
This E-mail and any files transmitted with it are confidential
and intended for the exclusive use of the addressee(s) only.
 You should not disclose its contents to any other person.
If you are not the intended recipient please notify the sender
immediately.
**********************************************************************
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.



--