The problem of class not found exception is still persists.
<b>Problem:</b>
As above said, each application is loaded by its own class loader. When a request comes for a web service, the service is calling a class which is in web services class loader. In turn the tracer is looking for ModifyHandler class which is bundled with custom observer (deployed as service inside Web AS). The class loader reference is existed from Observer to web service, but not in opposite direction. This causes ClassNotFoundException for ModifyHanlder class.
<b>What we did?</b>
1) When we put the Observer jar file in Framework class loader path (i.e. <installpath>/j2ee/server0/bin/system), it’s complaining of the classes which are related to webservices class loader.
This is because of Framework class loader is parent of Web Services class loader, which doesn’t know about those classes. To solve this problem we put the webservices.jar and related jars in the same Framework class loader path, this caused the server not to run, as the webservices are also deployed as core services of Web AS.
2) We thought to create a separate service consists of modify handler on which webservices service need to have a reference to solve the above problem. As the Web Services are core service in Web AS, this is not allowing us to make this service referencing our custom made services. We could not able to find out the ways through which we can dependant services to webservices service.
Do you think the second point make sense?
<b>Please help us in resolving the class loader problem is SAP Web AS. This is very urgent.</b>
Following points explain about basic class loading mechanism of SAP, cause of the problem and approaches we tried to resolve this.
<b>In Short the steps involved for loading of a class for an application is as follows:</b>
1. Checks that the class is not loaded by other concurrent thread.
2. Checks own negative cache – monitors whether any previous attempts to load this class have failed.
3. Tries to load the class through its parent class loader. If no parent class loader is set, the default parent class loader is the system classLoader.
4. Tries to load the class through referenced class loaders – makes a call to the ClassLoader Manager for its references and tries to load the class through any of them. When a referenced class loader is called, it does not try to load the class through its references – only local class loading attempt is made. This is done to prevent cycles.
5. Tries to load the class locally – searches for the class in the resources, which directly belong to this class loader.
6. If the class is still not loaded, it is added to the negative cache, which is a synchronized structure. It is cleared when new resources are added to the class loader. In this case, a ClassNotFoundException is thrown.
<b>About SAP Web AS Class Loading:</b>
The SAP Web AS offers an extended Java classloading model which is based on expansions of the default classloaders in Java. This extended Java classloading model allows the usage of classloader references from and to a classloader. Relationship between referenced classloaders is like associations between classes with the cardinalities 1:1.
Assumed, a class shall be loaded via classloader B, now not only the steps of the standard Java classloading will be executed. In this case, the class is first attempted to be loaded with the help of classloader A which is the parent classloader of classloader B. If loading the class in the parent classloader hierarchy is not successful, the extended Java classloading model of SAP comes into action. It will try to load the class from the directly referenced classloader D. It will, though, not try to load the class from the parent classloader of the referenced classloader D and also not from classloader F, which is referenced by classloader D
Only if neither the parent hierarchy nor the referenced classloaders could deliver the class, the original classloader B will try to load the class from its class resource locations. Also classloading references have no transitive behavior.
The classes of every server component (services, applications) become instantiated in a separate classloader. The Java kernel and the API's framework have also separate classloaders.
The parent classloader of a J2EE application is the server’s Frame Classloader and above this resides the System Classloader which grants access to all J2SE classes and all classes in the server classpath.
The class loading is accomplished only up towards the System classLoader. No opposite direction of loading is available.
The J2EE Engine class loading system is centralized in the ClassLoader Manager. It implements functionality used for registering and removing loaders and references between them, as well as for accessing these loaders. The ClassLoader Manager keeps a hash table of all referenced loaders. The loader name is used in this table as a key, which is unique.
<b>Class loading system comprises several different types of loaders.</b>
1) Core layer – the lowest level. The Core Layer appears as a group of managers that offer I/O, thread management, clustering, client connections manipulation, configuration management.
2) Components layer – implements all that is required to comply with the J2EE specification (containers, naming, and so on), including helper services for maintaining persistent data, security service, file copying service, and RMI over P4 protocol (excerpt).
3) Framework layer – the medium between managers and services is called the service framework. It contains interfaces for structured and convenient access to the managers’ functionality.
4) Application layer – deployed applications are the highest and most volatile level of abstraction.
Classloaders in a cluster node are isolated to offer access to specific and unique bundles of classes only. When loading a class, a class loader first delegates the search for the class to its parent class loader before iterating through its registered references from the ClassLoader Manager, and finally attempts to find the class itself.
Classloader references are described in the SAP specific J2EE service descriptor provider. xml. Two types of references can be set by a component to another component. Both types can be set only in one direction.
Weak references will be used if classes are used between two components. If a second component exists a classloading reference will be set from the first component to the second component. Cycles of weak references for J2EE applications are not permitted.
Strong references will be used if the object dependency between two components is functional rather than just of a class-sharing type. If a second component exists, a classloading reference will be set from the first component to the second component.
regards,
Suresh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.