How to get JVM version under WebSphere?

[a...@mail.nerc-essc.ac.uk]

Hi,

I have a Sun java runtime JDK1.5.0_04.

How can we find out for sure which JVM version is being used by WAS 6.0 ? I am trying to install some JAI libs from:

http://java.sun.com/products/java-media/jai/downloads/download-1_1_2_01.html

http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jaii o-1.0_01-oth-JPR&SiteId=JSC&TransactionId=noreg

which i successfully installed. However, when i am running my application, it is giving me a class not found error message which points out that WAS is not picking up the jar files. Im not sure if Websphere is using that jdk?

How do i check this and bring the changes?

cheers,

Adit

[David Currie]

If you're running WAS 6.0 then you won't be using a 1.5 JDK and it
certainly won't be Sun unless you're running on Solaris.

Regards,
David

[a...@mail.nerc-essc.ac.uk]

ok, how can i install the jai libraries in websphere?

[EHab...@technoserv.ru]

> picking up the jar files. Im not sure if Websphere is
> using that jdk?

WAS has it's own JDK inside.
For WAS 6.0 JDK version is 1.4.2.
If you want to use JDK version 1.5.0, you have to install WAS 6.1.

Current WAS JDK Level you can view, if you run "java -version" from
$(was.install.root)\java\bin

For example:

C:\Program Files\IBM\WebSphere\AppServer\java\bin>java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20060421 (SR5) (J
IT enabled: jitc))

--
WBR, Evgeniy Khabarov

[a...@mail.nerc-essc.ac.uk]

allrite, in that case, i need to install the jai libs in the webshere JVM.

thanks for the help

[Dexthor]

a...@mail.nerc-essc.ac.uk wrote:
> allrite, in that case, i need to install the jai libs in the webshere JVM.
>
> thanks for the help

If you need these jai libs to be available to an Application running on
WebSphere6, you dont have to drop them into $JAVA_HOME. You have
various classloader options (Server, Boot Classpath, Shared Libraries,
Custom Classloaders etc.,) to use and yet achieve what you are looking
for.

Unless you have exhausted above safer options, you dont want to drop
non-WAS libs into the common area. If these libs are security
extentions to WAS or something that will be used by majority of the
Apps running in that environment, then it is justified.

-Dexthor.

[ads...@examscam.com]

Why do classloaders come up so often?

Try the lib or lib\app directory of WebSphere.

Here's some more detail on WebSphere Classloaders, and how a perfectly
planned application can end up with file not found errors. :(

http://www.technicalfacilitation.com/get.php?link=classloading

Cheers!

-Cameron McKenzie
Author of What is WebSphere?

Free WebSphere Tutorials: www.pulpjava.com
Free Java Certification Mock Exams: www.scja.com
Good Books on WebSphere Certification: www.examscam.com

Java applications run on a Java Virtual Machine (JVM).

Our J2EE applications run on a Java Virtual Machine as well, after all,
they are written in Java.

In the WebSphere world, the JVM that our J2EE applications run on is
often referred to as an 'application server,' since it is
responsible for serving our J2EE applications up to clients. Under the
covers though, an application server is nothing more than a souped-up
JVM running on the server.

If you are so inclined, you can even monitor the JVM responsible for
serving up your J2EE applications by bringing up the Windows Task
Manager and looking for the java.exe process that's hogging your
memory and consuming all of your processor's clock cycles. That's
the Java Virtual Machine that enables your WebSphere applications.

J2EE applications are written in Java, and JVMs have the job of running
and executing the Java code you have written.

When a client calls a Servlet, or an EJB calls the constructor of a
JavaBean, compiled Java code, also known as bytecode, must be loaded
and subsequently run on a JVM. Finding the appropriate Java bytecode
file, and throwing that bytecode onto a piping hot JVM is the job of a
very special, and extremely important component known as a classloader.

Classloaders locate Java bytecode files and load that Java bytecode on
the JVM. Without a classloaders, our J2EE applications simply would not
work.

Important Java classes that must be loaded onto the Java Virtual
Machine in order to get our applications to perform properly include:

F classes that implement the basic Java runtime environment such as
java.lang.Interger

F the code IBM has written to support and implement the J2EE
specification

F EJBs and the JavaBeans they use to implement complex business logic

F all of the Servlets, JSPs and helper classes that make our web
based applications behave the way they should

Understanding how classloaders work is one of the most important
aspects of WebSphere development, packaging and deployment.
Unfortunately, classloading is also one of the most misunderstood
aspects of J2EE development, leading to innumerable problems at both
runtime and design time.

To understand how the WebSphere runtime works, you must have a good
grasp of J2EE classloading.