In this practice you look into the Java classpath for possible errors.
Oracle University and Sentra inversiones y servicios LTDA use only
Practice 7-1: Investigating Classpath Problems
Duration: 30 minutes Skills Learned
At the end of this practice, you should be able to:
• Locate and analyze a classpath error
• Browse application and server classes
• Debug server start scripts Overview
Java code is made available to a JVM process, such as WebLogic Server, through class loaders. Class loaders are typically associated with some set of locations on the file system.
The main JVM system class loader, for example, is configured by using the classpath argument.
Applications also have their own class loaders. While the system classpath can be set to any arbitrary file system paths and archives, WLS and the Java EE specification dictate from where application-specific code can be loaded.
In this practice, the MedRec system has been upgraded to utilize a new third-party library. While the application functions properly in the development environment, the production environment has encountered a class loading error. You investigate the contents of the application along with the system classpath.
Instructions
1. Set up the practice.
a. Locate a Lab Framework prompt or start a new one. Change directories to
<CURRENT_LAB>.
b. Execute the following:
ant setup_exercise The Lab Framework:
− Deploys a new version of the MedRec application
− Updates the MedRec domain files
c. Kill and restart the server MedRecSvr1. Be sure to continue using the provided startServer1.sh script.
2. Trigger a Class Not Found error.
a. Launch a Web browser and access the MedRec application:
http://localhost:7021/medrec/index.action
b. Log in as the patient Fred with: [email protected]/weblogic.
c. Click the Profile button.
d. Scroll down and click the Save button.
e. Confirm that the application fails and that you receive a generic HTTP 500 error.
f. Locate the Java error message in the log (or server output) for MedRecSvr1. It should resemble the following:
<Error> <HTTP> <BEA-101017> <[ServletContext@28172302[app:medrec module:medrec ...]]
Root cause of ServletException.
javax.faces.FacesException:
#{viewingPatientController.updatePatient}:
Oracle University and Sentra inversiones y servicios LTDA use only
javax.ejb.EJBException:
java.lang.NoClassDefFoundError:
org/integratex/mainframe/XAdapter at com.bea.medrec.service.impl.
PatientServiceImpl.updatePatient ...
...
at com.bea.medrec.web.controller.
ViewingPatientController.updatePatient ...
Tip: The original exception was triggered from MedRec EJB application code, but then was caught by the Java Server Faces (JSF) framework in the Web application and wrapped within a FacesException.
3. Investigate the application classpath.
After talking with the development team and searching the Internet, you have discovered that the missing class, XAdapter, is a component of a third-party library. Most of these resources also suggest that the class is typically found within an archive named
adapters.jar.
a. From the Linux File Browser, navigate to and open the
<LAB_WORK>/applications/medrec.ear file by using the Archive Manager.
b. Inspect the contents of the archive’s APP-INF/lib folder. Check for the presence of the file adapters.jar or a similarly named file.
c. Inspect the contents of the archive’s APP-INF/classes folder. Check for the presence of the following folders and file:
org/integratex/mainframe/XAdapter.class.
d. Continue your search within the following archives found in medrec.ear. Browse the indicated locations if they exist:
File Location
Tip: You must extract the WAR file in order to view it with the Archive Manager.
Tip: You can also search archives with command-line tools such as jar. For example:
jar tvf medrec.ear | grep –i "adapter"
4. Investigate the server classpath.
a. Continue your search at <LAB_WORK>/domains/MedRecDomain/lib.
Although your missing JAR file is not here either, you may notice an adapters.jar file in the domain’s root directory, MedRecDomain.
b. Locate the terminal running MedRecSvr1. Scroll up to the start script’s initial output.
Locate the line at which the script prints the current classpath:
JAVA Memory arguments:...
...
WLS Start Mode=...
Oracle University and Sentra inversiones y servicios LTDA use only
...
CLASSPATH=...
Tip: If necessary, you can restart the server to view its initial output.
c. Scan this output for the presence of the adapters.jar file. Can you spot the error?
5. Correct the classpath issue.
a. Search the following start script files to try to locate the line at which adapter.jar is added to the classpath:
MedRecDomain/bin/setDomainEnv.sh MedRecDomain/bin/startWebLogic.sh
MedRecDomain/bin/startManagedWebLogic.sh MedRecDomain/startServer1.sh
b. Remove this line from whichever script file in which you find it.
c. Move adapters.jar to the MedRecDomain/lib location.
Why? Any JAR file in the lib folder of a domain is automatically added to the classpath of servers in the domain.
Tip: Alternative solutions include adding the JAR to the MedRec application or deploying it as a shared library.
d. Restart the server by using a new Linux terminal. Confirm that the JAR is no longer in the classpath.
e. Repeat the earlier steps to test the MedRec application again. The user’s profile should now update with no errors:
Solution Instructions
No solution exists for this practice. To do this practice the MedRecDomain must exist. If the
<LAB_WORK>/domains/MedRecDomain location does not yet exist, follow the Solution Instructions for the “Developing a Custom Monitoring Script” practice.