Was6.1 class loading problem example

Was has provided a powerful and flexible class loading mechanism since Version 6.1, but it also brings complexity in use. It may have been a normal project running on v6.0, the classnotfound problem occurs after being transplanted to v6.1. Here is an example.

After a project is migrated from v6.0 to v6.1,

1. If you use the normal deployment method, the system always reports that the class cannot be found.

java.lang.ClassNotFoundException: com.ibm.bsf.engines.javascript.JavaScriptEngineat java.lang.Throwable.(Throwable.java:57)at java.lang.Throwable.(Throwable.java:81)at java.lang.ClassNotFoundException.(ClassNotFoundException.java:80)at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:405)at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:78)at java.lang.ClassLoader.loadClass(ClassLoader.java:561)at com.ibm.bsf.BSFManager.loadScriptingEngine(Unknown Source)at com.ibm.bsf.BSFManager.exec(Unknown Source)at com.utan.utanApp.bsf.BsfMgr.doTask(BsfMgr.java:92)at com.utan.utanApp.EJB.TaskMgr.UETaskMgrBean.doTask(UETaskMgrBean.java:98)at com.utan.utanApp.EJB.TaskMgr.EJSRemoteStatelessUETaskMgr_0137dc13.doTask(EJSRemoteStatelessUETaskMgr_0137dc13.java:115)at com.utan.utanApp.EJB.TaskMgr._UETaskMgr_Stub.doTask(_UETaskMgr_Stub.java:309)at com.utan.utanWeb.servlet.trx.DoTask.judge(DoTask.java:170)at com.utan.utanWeb.servlet.trx.DoTask.doPost(DoTask.java:61)at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:308)at com.utan.utanWeb.servlet.trx.MainServlet.forwardServlet(MainServlet.java:637)at com.utan.utanWeb.servlet.trx.MainServlet.doTask(MainServlet.java:305)at com.utan.utanWeb.servlet.trx.MainServlet.judge(MainServlet.java:194)at com.utan.utanWeb.servlet.trx.MainServlet.doPost(MainServlet.java:91)at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102)at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:193)at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:725)at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:847)at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)  

2. The application class loading method uses parent_last (originally parent_first). The above classnostfound problem is solved, but there is a new problem:

**** MessageBrokerServlet failed to initialize due to runtime exception: [1]java.lang.ClassCastException: com.ibm.ws.management.PlatformMBeanServer incompatible with javax.management.MBeanServerat flex.management.WebSphereMBeanServerLocator.getMBeanServer(WebSphereMBeanServerLocator.java:77)at flex.management.BaseControl.register(BaseControl.java:179)at flex.management.runtime.AdminConsoleDisplayRegistrar.<init>(AdminConsoleDisplayRegistrar.java:19)at flex.management.runtime.messaging.MessageBrokerControl.<init>(MessageBrokerControl.java:85)at flex.messaging.MessageBroker.<init>(MessageBroker.java:196)at flex.messaging.config.MessagingConfiguration.createBroker(MessagingConfiguration.java:104)at flex.messaging.MessageBrokerServlet.init(MessageBrokerServlet.java:106)at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:238)at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.init(ServletWrapper.java:351)at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1379)at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:184)at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:99)at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:910)at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:832)at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:550)at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:387)at com.ibm.ws.wswebcontainer.webapp.WebApp.initialize(WebApp.java:338)at com.ibm.ws.wswebcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:93)at com.ibm.ws.wswebcontainer.VirtualHost.addWebApplication(VirtualHost.java:162)at com.ibm.ws.wswebcontainer.WebContainer.addWebApp(WebContainer.java:673)at com.ibm.ws.wswebcontainer.WebContainer.addWebApplication(WebContainer.java:626)at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:395)at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:611)at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1274)at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1164)at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:591)at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:831)at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:945)at com.ibm.ws.runtime.component.ApplicationMgrImpl$AppInitializer.run(ApplicationMgrImpl.java:2120)at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:342)at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1551)

This is a flex application that uses a ready-made jar package. It seems that the class usage conflicts and the class loading sequence is still a problem. However, due to lack of understanding about this package, in a short time, it is impossible to determine which class and which class are abrupt.

Solution:

It seems that point 2nd is more difficult to solve than point 1st, so we should start with the first point to solve the class loading problem.

If the default class loading policy is still used: parent_first, The Org. eclipse. osgi. framework. internal. core. the bundleloader loader does not seem to find the javascriptengine class at this loader level. In fact, javascriptengine and bsfmanager are in the same package.

A feasible solution is to convert the BAF. jar (the jar package where the javascriptengine class is located) is copied to the JRE/lib/EXT directory, then Org. eclipse. osgi. framework. internal. core. the bundleloader class loader can be found, because the JDK loading sequence is in org. eclipse. osgi. framework. internal. core. bundleloader first.

However, the system administrator is in security considerations and does not agree to place the BSF. jar package under the JRE. It seems that we have to find another method. By reading the following article and understanding the Loading Method of was6.1, we can see that creating an application shared library can solve this problem. Refer:Use shared libraries at the application server level. Note:Use shared libraries at the application levelThis problem cannot be solved. It should be feasible if the class does not use its classloader.

Detailed operation steps:

1. Open the was6.1 console and create a shared library.

2. Use the Shared Library at the application server level

Create a class loader.The class is loaded and the Application Loader is used first.Option

Save

Class Loader created

Reference for creating a shared library

Select a shared library that has been configured

The configuration is complete.

The following is a reference document

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Understanding was 6.1 class loading (4)

　　12.5.2 Step 2: add an EJB module and tool jar

Next, add an EJB to the application. It also depends on the versionchecker JAR file. Add a versioncheckerv2.jar file to the root directory of the ear. The versionchecker class in this jar file returns version 2.0. To ensure that the jar tool in the extension class loading is available, add a reference to the manifest file of the EJB module, for example, 12-8:

　　Example 12-8 update the manifest. MF file of the EJB Module

Manifest-version: 1.0

Class-path: versioncheckerv2.jar

Now the result is: there is a web module with a servlet under its WEB-INF/classes directory and the versioncheckerv1.jar file under the WEB-INF/lib directory. Another EJB module references the versioncheckerv2.jar tool jar under the ear root directory. What version do you expect the web module to load versionchecker files? Is version 1.0 in WEB-INF/lib or version 2.0 in tool jar? Test result example 12-9:

Example 12-9 class loading Example 2

Versionchecker called from Servlet

Versionchecker is v2.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 26282628

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleejb. jar; C: \ WebSphere \ appserv

Er \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ classloaderexample

. Ear \ versioncheckerv2.jar

Delegation mode: parent_first

Versionchecker called from EJB

Versionchecker is v2.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 26282628

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel L \ classloaderexample. Ear \ classloaderexampleejb. jar; C: \ WebSphere \ appserv

Er \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ classloaderexample

. Ear \ versioncheckerv2.jar

　　Delegation mode: parent_first

As you can see, when the EJB module and the web module are called at the same time, versionchecker is version 2.0. Of course, the reason is: The War class loader delegates the request to the parent class loader instead of its own, so the tool jar is loaded by the same class loader, you don't need to consider whether the request comes from servlet or EJB.

　　12.5.3 Step 3: Change the delegate mode of War class loading

Do you want the web module to use the versioncheckerv1.jar file below the WEB-INF/lib directory? For this purpose, you must first change the class loading delegation mode from parent first to parent last.
　
Set the delegate mode to parent_last. follow these steps:

1. Select enterprise applications in the Wizard bar;

2. Select the classloaderexample application;

3. Select Manage modules in the module section;

4. Select the classloaderexampleweb module;

5. Modify the class loading sequence to parent_last ). Remember, this entry should be called War class loading first. For details, see "class loading/delegation mode ";

6. Click OK.

7. Save the configuration;

8. Restart the application.

Versioncheckerv1 under the WEB-INF/lib returns version of 1.0. You can see in example 12-10:

Example 12-10 class loading Example 3

Versionchecker called from Servlet

Versionchecker is V1.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 4d404d40

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Classes; C: \ W

Ebsphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ Cl

Assloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Lib \ versioncheck

Erv1.jar; C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8

Node02cell \ classloaderexample. Ear \ classloaderexampleweb. War

Delegation mode: parent_last

Versionchecker called from EJB

Versionchecker is v2.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 37f437f4

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleejb. jar; C: \ WebSphere \ appserv

Er \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ classloaderexample

. Ear \ versioncheckerv2.jar

Delegation mode: parent_first

If you use the search function of the class loader to search for * versionchecker *, figure 12-9 is displayed:

Figure 12-9 loading the viewer search function

Example 12-11 show source code

Example 12-11 loading the viewer search function

Was module compound Class Loader (War class loader ):

File:/C:/WebSphere/appserver/profiles/invalid rv02/

Installedapps/kcgg1d8node02cell/classloaderexample. Ear/

Classloaderexampleweb. War/WEB-INF/lib/versioncheckerv1.jar

Was module jar Class Loader (Application Class Loader ):

File:/C:/WebSphere/appserver/profiles/invalid rv02/

Installedapps/kcgg1d8node02cell/classloaderexample. Ear/

Versioncheckerv2.jar

　　12.5.4 Step 4: Use the shared library sharing tool jar

Before that, only one application uses the versioncheckerv2.jar file. Do you want multiple applications to share it? Of course, you can package this file in each ear file. However, if you need to modify the jar tool, you need to redeploy all applications. To avoid this problem, you can use the shared library to globally share the JAR file.

Shared libraries can be defined in units, nodes, application servers, and clusters. Once you have defined a shared library, you must associate it with the class loader of the application server or a separate web module. According to the destination assigned by the shared library, WebSphere uses the matching class loader to load the shared library.

You can define multiple shared libraries as long as you want. You can also assign multiple shared libraries to applications, web modules, or application servers.

　Use shared libraries at the application level

Define a shared library named versioncheckerv2_sharedlib and associate it with the classloadertest application. The steps are as follows:

1. on the console, select environment → shared libraries;

2. Select the scope of the shared library, such as the unit, and click New;

3. 12-10:

Figure 12-10 shared library Configuration

-Name: Enter versioncheckerv2_sharedlib;

-Class path: entries in the input class path, separated by carriage return. If the absolute path is provided, we recommend that you use WebSphere environment variables, such as % framework_jars %/versioncheckerv2.jar, to confirm that you have defined a variable with the same scope as the shared library.

-Native library path: Enter the list of DLLs and. So files used by JNI code.

4. Click OK;

5. select applications → enterprise applications;

6. Select the application classloadersexample;

7. In the reference option, select shared library references;

8. Select classloaderexample in the application column;

9. Click reference shared libraries;

10. Select versioncheckerv2_sharedlib and click> to move the selected content to the selected column, such as 12-11:

Figure 12-11 specify a shared library

11. Click OK;

12. The configuration window for the shared library of the classloaderexample application is 12-12:

Figure 12-12 assign the Shared Library to the application classloaderexample

13. Click OK to save the configuration.

If we delete versioncheckerv2.jar from the root directory of the ear file, delete the reference in the manifest file of the EJB module, restart the application server, and see the result of example 12-12. Remember, the class loading sequence of the web module is still the application class loading priority (parent_last ).

　Example 12-12 loading Example 4

Versionchecker called from Servlet

Versionchecker is V1.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 2e602e60

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Classes; C: \ W

Ebsphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ Cl

Assloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Lib \ versioncheck

Erv1.jar; C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8
　
Node02cell \ classloaderexample. Ear \ classloaderexampleweb. War

Delegation mode: parent_last

Versionchecker called from EJB

Versionchecker is v2.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 19141914

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleejb. jar; C: \ Henrik \ versionche

Ckerv2.jar

Delegation mode: parent_first

As expected, the versioncheckerv1.jar file is loaded when the servlet needs the versionchecker class due to the web module's delegation mode. When the EJB needs versionchecker class, it will be loaded from the shared library pointing to c: \ Henrik \ versioncheckerv2.jar. If you want the web module to use a shared library, you only need to restore the class Loading Order to the default value. The class loading of the web module takes precedence over the parent class loading.

　Use shared libraries at the application server level

Shared libraries can also be associated with application servers. All applications deployed on this server can view the code list of the shared library. To associate the shared library with the application server, you must first create an additional Class Loader for the Application Server. The steps are as follows:

1. Select the application server;

2. In the application infrastructure section, expand Java and process management and select class loader;

3. Select New to select the class loading sequence for this Class Loader. The parent class is preferentially loaded (parent_first) or the application class is preferentially loaded (parent_last), and click Apply;

4. Click the class loader you just created;

5. Click shared library references;

6. Click Add and select the database to be associated with the application server. Repeat the selection operation to associate multiple databases with this class loader. For example, select the versioncheckerv2_sharedlib entry;

7. Click OK;

8. Save the configuration;

9. Restart the application server to make the modification take effect.

Associate the versioncheckerv2 shared library with the application server. The result of example 12-13 is displayed.

Example 12-13 class loading Example 5

Versionchecker called from Servlet

Versionchecker is V1.0.

Loaded bycom. IBM. ws. classloader. compoundclassloader @ 40c240c2

Local classpath:

C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cel

L \ classloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Classes; C: \ W

Ebsphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8node02cell \ Cl

Assloaderexample. Ear \ classloaderexampleweb. War \ WEB-INF \ Lib \ versioncheck

Erv1.jar; C: \ WebSphere \ appserver \ profiles \ invalid rv02 \ installedapps \ kcgg1d8

Node02cell \ classloaderexample. Ear \ classloaderexampleweb. War

Versionchecker called from EJB

Versionchecker is v2.0.

Loaded bycom. IBM. ws. classloader. extjarclassloader @ 7dee7dee

Local classpath: C: \ Henrik \ versioncheckerv2.jar

Delegation mode: parent_first

The new Class Loader named extjarclassloader is defined. When the EJB module requests, it loads the versioncheckerv2.jar file. Due to the delegate mode, the war Class Loader continues to load its version.

　　Diagnosis of 12.6 class loaders

JVM 5.0 provides some configurations for you to view detailed class loading, such as the JVM parameter-verbose: dynload,-dibm. Cl. verbose = <Name>.

In the actual development process, if improperly used, many class loading problems may occur. When a class loading problem occurs, you can view the was logs. The following exception occurs in the logs, which can be considered as a problem with the Class Loader:

Classcastexception

Classnotfoundexception

Noclassdeffounderror

Nosuchmethoderror

Illegalargumentexception

Unsatisfiedlinkerror

Verifyerror

For problem diagnosis, we will elaborate in the next article "was 6.1 class loading problem diagnosis.

　　Summary

This article introduces the concept of class loading and how to customize it for was6.1, and describes how to use the options that affect class loading through several examples. Although was 6.1 allows you to modify the class loading policy as needed, for example, changing the parent class to the application priority is not recommended. I have encountered that the application cannot be started due to policy modification. The reason is that the components in was are the same as some classes used by the application. If the loading policy is incorrect, the class loading error occurs.

Source: http://gocom.primeton.com/blog15911_23254.htm