Connector Class Loader in OC4J Classloader Tree

Where does connector class loader fit in the OC4J class loader tree. Is it a parent to the EJB Classloader (as in SunOne) or does it use its own classloader to load classes (similar to weblogic). Becos it can impact visibility into resource adapter's classes.

The classloader tree in the ClassLoadingInOC4J_WP.pdf applies to 10.1.2 and 9.0.4, probably even earlier, where the connector classcloader is the root classloader of an application.
For 10.1.3, the root classloader of an application loads both connector jars and ejb jars. See chapter 3 of Oracle Containers for J2EE Developer's Guide(10.1.3 preview).

Similar Messages

How to recover from an exception on a class loaded with a classloader?

I have created a classloader for the purpose of dynamically loading "modules" . The whole application is multithreaded and the separate modules may also run as separate threads. The problem that I am facing is that if one of the modules crashes (does not handle an exception), then the class loader object which loaded the required classes and started the module's thread, cannot be accessed. The thread which attempts to access this class loader freezes. Is there any way to recover from this situation?
Thanks in advance

Ok, let me provide a bit more information. Each "module" is handled by specific class (let's call it ModuleDescriptor), which subclasses the URLClassLoader class. The ModuleDescriptor class is responsible for describing each module, maintain module state information (loaded, unloaded, started, stopped, etc) and also executing some method calls on a specific object of the module, which in essence acts as a means to start or stop the module. Each module is a separate thread and is packaged in a JAR file, which is first downloaded locally. If one of these module threads crashes, then I cannot even call a method of the ModuleDescriptor to perform the necessary unloading bit. Basically, when I can the method that thread of execution halts without an exception or an error or anything. The rest of the application continues working properly (other threads). I find this situation bizarre, because the ModuleDescriptor object and the actual module with the thread that crashed execute on separate threads. If there is any more specific information that I have to provide, please let me know.

Getting all classes loaded by ClassLoader?

How do you get an array of type (Class []) that represents all the classes loaded by a ClassLoader?
Thanks
neofreezer

but if you do, that means that u can't load classes whose packages start with 'java.'!

How to load a class dynamically in the current/system class loader

I need to dynamically load a new jdbc driver jar to the current/system class loader... Please note that creating a new classloader will not help since the DriverManager refers to the systemclassloader itself.
Restarting the application by appending the jar to its classpath will solve the problem but I want to avoid doing this.

Did you then create a ClassLoader to load the JDBC
driver and then install it into the system as
directed by the JDBC specification (ie
Class.forName(someClassName))?
And then try to use it from a class loaded fromsome
other ClassLoader (i.e. the system class loader)?
If you did not try this please explain why not.O.K. I just looked at the source to
java.sql.DriverManager. I did not know what I was
talking about, as what I suggested above will not
work.
This is my new Idea:
Create a URLClassLoader to load the JDBC driver also
in this ClassLoader you need to place a helper class
that does the following:
public class Helper {
public Driver getJDBCDriver(String driverClassName,
String url) {
try {
Class.forName(driverClassName);
Driver d = DriverManager.getDriver(url);
return d;
catch(Exception ex) {
ex.printStackTrace();
return null;
}Now create an instance of the Helper class in the new
ClassLoader, and call its getJDBCDriver method to get
an instance of the driver (you will probably have to
create an interface in the root class loader that the
Helper implements so that you can easily call it).
Now from the root classloader you can make calls
directly to the returned Driver and bypass the
DriverManager and its restrictions on cross
ClassLoader access.
The only catch here is that you would have to call to
the returned Driver directly and not use the Driver
Manager.This sounds like will work but I did not want to load DriverManager in a new classloader.. I did a hack
I unzip the jar dynamically in a previously known location (which I included in my classpath when launching the app). The classLoader finds the class now though it did not exist when the app was launched !
A hack of-course but works eh ..

Dynamic Class Loading in an EJB Container

Hello,
We have a need to load classes from a nonstandard place with in an ejb container, ie a database or secure store. In order to do so we have created a custom class loader. Two issues have come up we have not been able to solve, and perhaps some one knows the answer to.
Issue 1.
Given the following code:
public static void main(String args[])
MyClassLoader loader = new MyClassLoader("lic.dat");
System.out.println("Loading class ..." + "TestObject");
Object o = Class.forName("TestObject",true,loader).newInstance();
System.out.println("Object:" + o.toString());
TestObject tstObj = (TestObject) o;
tstObj.doIt();
What happens when executed is as follows. Class.forName calls our loader and does load the class as we hoped, it returns it as well, and the o.toString() properly executes just fine. The cast of the object to the actual TestObject fails with a class not found exception. We know why this happens but don't know what to do about it. It happens because the class that contains main was loaded by the system class loader (the primordial class loader as its sometimes called), That class loader does not know about TestObject, so when we cast even though the class is "loaded" in memory the class we are in has no knowledge of it, and uses its class loader to attempt to find it, which fails.
> So the question is how do you let the main class know to use our class loader instead of
the system class loader dispite the fact is was loaded by the system class loader.
Issue 2:
To make matters worse we want to do this with in an EJB container. So it now begs the question how do you inform an EJB container to use a specific class loader for some classes?
Mike...

Holy crap! We are in a similar situation. In creating a plugin engine that dynamically loads classes we use a new class loader for each plugin. The purpose is so that we can easily unload and/or reload a class at runtime. This is a feature supposedly done by J2EE app servers for hot-deploy.
So our plugins are packaged as JAR files. If you put any class in the CLASSPATH, the JVM class loader (or the class loader of the class that is loading the plugin(s)), will load the class. The JavaDoc API states that the parent classloader is first used to see if it can find the class. Even if you create a new URLClassLoader with NULL for parent, it will always use the JVM class loader as its parent. So, ideally, in our couse, plugins will be at web sites, network drives, or outside of the classpath of the application and JVM.
This feature has two benefits. First, at runtime, new updates of plugins can be loaded without having to restart the app. We are even handling versions and dependencies. Second, during development, especially of large apps that have a long startup time, being able to reload only one plugin as opposed to the annoying startup time of Java apps is great! Speeds up development greatly.
So, our problem sounds just like yours. Apparently, the Client, which creates an instance of the plugin engine, tries to access a plugin (after the engine loades it via a new classloader instance for each plugin). Apparently, it says NoDefClassFound, because as you say, the client classloader has no idea about the plugin class loaded by another classloader.
My co-developer came up with one solution, which I really dont like, but seems to be the only way. The client MUST have the class (java .class file) in its classpath in order to work with the class loaded by another class loader. Much like how in an EJB container, the web server calling to EJB MUST contain the Home and Remote interface .class files in its classpath, the same thing needs to be done here. For us, this means if a plugin depends on 5 others, it must contain ALL of the .class files of those plugins it depends on, so that the classloader instance that loads the plugin, can also see those classes and work with them.
Have you got any other ideas? I really dislike that this has to be done in this manner. It seems to me that the JVM should be able to allow various class loaders to work with one another in such a way that if a client loaded by one classloader has an import statement in it to use a class, the JVM should be able to fetch the .class out of the other classloader and share it, or something!
This seems to me that there really is no way to actually properly unload and then reload a class so that the JVM will discard and free up the previous class completely, while using the new class.
I would be interested in discussing this topic further. Maybe some others will join in and help out on this topic. I am surprised there isn't a top-level forum topic about things like class loaders, JVM, etc. I wish there was a way to add one!

Cusotm Class Loader

I'm trying to use a custom class loader to load specific classes (not handle everything). So in those particular situations I call my custom class loader's loadClass method which will first check for a .class file in a specific directory and use that, otherwise it will get from classpath.
While testing, it worked perfectly fine. If I didn't put a class file in the directory it used the one from classpath, but as soon as I put the class in the directory then that class would override whatever was in my classpath- perfect.
However, when I deployed this to WebLogic, the system broke. It seems to load the class fine but during class definition it can not find the other objects I reference within the class, so I get NoClassDefFoundError errors.
Here's what the code looks like:
    public synchronized Class loadClass(String className, boolean resolveIt, String filePath)
         throws ClassNotFoundException {
        Class result;
        byte classData[];
        /* Check our local cache of classes */
        result = (Class)classes.get(className);
        if (result != null) {
            return result;
        /* Try to load it from our repository */
        classData = getClassFromFile(className, filePath);
        if (classData != null) {
            //System.out.println(" found in file");
            /* Define it (parse the class file) */
            result = defineClass(classData, 0, classData.length);
            if (result == null) {
                throw new ClassFormatError();
            if (resolveIt) {
                resolveClass(result);
            classes.put(className, result);
            return result;
        /* Try the classpath */
        return Class.forName(className);
    }any idea what's up?

I think the "linkage" to types(classes, interfaces) referenced by a class are resolved at the resolveClass method, not the defineClass method. Are you sure that's the method throwing the exception?
anyway, what I meant is that when a class loaded by your classloader is resolved(linked to all refernced types), the referenced types are searched by your classloader, so you have to ensure it delegates to the appropriate class loader.
lets say your WebLogic server configuration consists of an EJB/dependency classloader, and a descendent WAR classloader.
If for example, your classloader is located in a dependency jar, hence loaded by the EJB/dependency classloader, any classes loaded by it that refer to types in the WAR will fail, because they will never get to the WAR classloader.
I think you should simply create your classloader with a specified parent instead of relying on the classloader that loaded it as a parent.
Better yet -> I know there are configurations that can be done on some servers(I don't have expirience with WebLogic, but I know it can be done with WebSphere) to configure the behavior you are looking for.
for example, setting delegation mode to "parent last" on a WAR classloader if you want all classes in WEB-INF/lib to have "priority" over classes on server classpath.
If this is possible in your case I'm sure it's better than messing around with implementing a custom classloader...

Oc4j class-loading-heirarchy - enabling "search-local-classes-first" option

Guys,
I need some assistance with regards to oc4j class-loading hierarchy. Would appreciate some feedback on this...
Let me give you a bit of context first.
Basically we have 3 war modules which we initially were deployed separately on oc4j (transparently deployed by oc4j as ear). Now all of a sudden we have come to the need of instead bundling all the wars in one ear. The problem i started seeing is with respect to the output logs for the application, which was one per war modules initially (this was not clutter everything in one single log file and instead have one per deploy-able unit). The way this was implemented is that we had a log4j.properties bundled with each war with the output-file configuration, and since these 3 wars were deployed separately, the ear class-loader for each application would find one log4j.properties within each, and hence output-logs were generated as expected.
BUT now all of a sudden as we have changed the whole deployment structure, i.e. one EAR, all the application log-outputs are going to one single log file (instead of one for each war). My immediate impression was setting the "search-local-classes-first" would resolve this issue, since then the "web-module-class-loader" (one for each war) would come into play (which i believe doesn't otherwise) and would load/search for the resources/classes first (log4j.properties in our case) from the web-module (both in WEB-INF/lib and WEB-INF/classes folder) and if not found, only then it would give the job to the parent class-loader, which would be the ear-class-loader. But it doesnt seem like its working like that, since even after enabling this option, all logs are going to one log-output file, based on whichever war-module/log4j.properties is loaded first.
Thanks in advance and Regards,
Farhan.
Edited by: FarhanS on Nov 3, 2008 12:36 PM

Guys, i need some input here....
I turned on the class-loading trace and found out as to what is going on...but still wondering as to whats the reason for this behavior...
So basically browsing through the trace, gave me the following important segments (as below with my comments)....
1) Firstly, as the class-loading trace below, the log4j.jar is loaded up from the ear/lib directory (and hence by the ear-class-loader) and as it says the one in the web-inf/lib is ignored....Wonder why it picks up the one from ear/lib directory WHEN i have set the search-local-classes-first to "true", isn't the very purpose of the attribute to delegate the class-loading to the parent class-loader IFF the same is not found locally...
Code-source /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/lib/log4j-1.2.15.jar (from WEB-INF/lib/ directory in /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/lib)
has been ignored. It is a copy of /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib), which is already visible in the search path of
loader wes-ear.web.wes-wicket-1.3.X-SNAPSHOT:0.0.0. 2) Now on the other hand as you would see from the log-excerpts below, the log4j.properties resource file (with the log-output-file-name and all) is picked up from the very web-module class-loader, but as you would notice further, the log4j classes are initialized by the ear-loader itself with which the log4j classes are visible to all the other war-modules and hence don't even require re-initializing the log4j.properties...
====== THE RESOURCE CORRECTLY LOCATED BY THE WEB-CLASS-LOADER ======
Resource found: log4j.properties. Loader: wes-ear.web.wes-wicket-1.3.X-SNAPSHOT:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/classes/
(from WEB-INF/classes/ in /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/classes)
=== ALL THE Log4j CLASSES BELOW ARE BEING INITIALIZED/LOADED BY THE EAR-CLASS-LOADER =====
Class found: java.net.URL. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
Class to be defined: org.apache.log4j.PropertyConfigurator (12024 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class found: org.apache.log4j.PropertyConfigurator. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class to be defined: org.apache.log4j.helpers.FileWatchdog (1875 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class found: org.apache.log4j.helpers.FileWatchdog. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class to be defined: org.apache.log4j.PropertyWatchdog (753 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class found: org.apache.log4j.PropertyWatchdog. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class found: java.io.InputStream. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
Class found: java.io.FileInputStream. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
Class found: java.util.Properties. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
Class found: java.util.StringTokenizer. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
Class to be defined: org.apache.log4j.Appender (676 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class found: org.apache.log4j.Appender. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class to be defined: org.apache.log4j.DailyRollingFileAppender (5724 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
Class to be defined: org.apache.log4j.FileAppender (4764 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)Thanks in advance and Regards,
Farhan.
Edited by: FarhanS on Nov 4, 2008 2:43 PM
Edited by: FarhanS on Nov 4, 2008 2:47 PM

Why won't -Djava.system.class.loader make it use my ClassLoader?

I created a class MyAppLoader and installed it in the bootclasspath and used the system property -Djava.system.class.loader. Yet, the JVM won't use my classloader! It's never instantiated (I have a static bit that prints code if it's loaded at all).
How do I make the JVM use my class as the system classloader?

send to me some Duke, please Any particular one? I hear the Duke of Northumberland is quite a laugh - would he do?

Java Connector. "sapjcorfc.dll already loaded in another classloader"

Dear all:
I'm fighting against a Java Connector problem.
I'm using:
-JCO version 2.16
-Apache Tomcat 5.5.17
I have written the environment variables:
CLASSPATH pointing where I have sapjco.jar, sapjcorfc.dll
Path where i have sapjco.jar, sapjcorfc.dll.
I try to make a webservice which calls a RFC function in SAP.
Java program compiles and Deploy OK.
I load the web service in Tomcat.
When I call the java server page, I get this error message from Tomcat:
org.apache.jasper.JasperException: JCO.classInitialize(): Could not load middleware layer 'com.sap.mw.jco.rfc.MiddlewareRFC'
JCO.nativeInit(): Could not initialize dynamic link library sapjcorfc Native Library C:\Traspas\Projecte\lib\sapjcorfc.dll already loaded in another classloader. java.library.path C:\Tomcat5.5.17\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Java\jdk1.5.0_07\bin;C:\Traspas\Projecte\lib
     org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)
     org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
     org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
     org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
     javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
Seems that is trying to load twice sapjcorfc.dll?
I would be grateful if someone can give me help.
Thanks in advance.
Jordi

I received a message asking for further clarification. I try to further explain.
Be sure sapjco.jar is not included in the application. Doing so will lead the system to load more than one time the SAP Java Connector. Sapjco.jar has to be loaded only once in the server.
To do so (in Windows & Tomcat environment):
1-Be sure sapjco.jar is not included in the WEB-INF folder.
2-Put sapjcorfc.dll and librfc32.dll in c:Windowssystem32
3-Put sapjco.jar in c:Tomcatcommonlib
4-Add a reference to sapjco.jar in the project (In Eclipse: Project/Properties/Java Build Path, Tab Libraries, Add External JARs.
5-Compile and deploy the application. Generate War file. If ant gives problems, add proper command to find sapjco.jar (section <path id=u201Dpath.baseu201D>, <include name=u201Dsapjco.jaru201D>)
6-Load the WAR file in Tomcat.
7-Stop and Start Tomcat.
8-Run the application.
A related thread: [SAP J2EE engine problem|SAP J2EE engine problem]
Hope this helps.

Problem in Class Loading

I am using Sun implementation of JAXB(jaxb-api.jar) for java-to-xml binding in my web application deployed in the latest version of oracle app server(10g release 3). The web server is loading Oracle implementation of JAXB from the shared archive xml.jar. To direct the web server to load application specific JAXB classes, I have used the property(<web-app-class-loader search-local-classes-first="true" include-war-manifest-class-path="false" />) in the deployment description - orion.xml file. But it does not solve the problem!
Thanks & regards

Hi,
Refer to this link on OC4J's Classloading Framework... http://download-east.oracle.com/docs/cd/B25221_04/web.1013/b14433/classload.htm#sthref58 there are a couple of options you may be able to employ, including overriding the shared library - there is an example of doing this with the Oracle XML parser and Xerces.
I'm guessing you're on the right track, but you may want to try include-war-manifest-class-path="true". Also, are you sure that you've got your deployment descriptor file defined correctly? Its normally called orion-application.xml, and that particular element isn't defined in the documentation (http://download-east.oracle.com/docs/cd/B25221_04/web.1013/b14433/descriptors.htm#sthref337). You could always try configuring it through the administration console.

Class loader Exception

I am getting the following error even though the corresponding file is present in the app.jar.
This happens when hibernates are getting loaded , when i start the oracle app server.
Does anyone knows why its so.
Caused by: org.hibernate.MappingException: entity class not found: com.iflex.fcr.app.deposit.td.us.dto.DepositRateHistoryDTOCheckNew
     at org.hibernate.mapping.PersistentClass.getMappedClass(PersistentClass.java:99)
     at org.hibernate.tuple.PropertyFactory.getGetter(PropertyFactory.java:166)
     at org.hibernate.tuple.PropertyFactory.buildIdentifierProperty(PropertyFactory.java:44)
     at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:115)
     at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412)
     at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108)
     at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
     at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:216)
     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
     at com.iflex.fcr.infra.das.orm.hibernate.SessionFactoryLoader.<clinit>(Unknown Source)
     ... 5 more
Caused by: oracle.classloader.util.AnnotatedClassNotFoundException:
     Missing class: com.iflex.fcr.app.deposit.td.us.dto.DepositRateHistoryDTOCheckNew
     Dependent class: org.hibernate.util.ReflectHelper
     Loader: global.libraries:1.0
     Code-Source: /D:/product/10.1.3.1/OracleAS_3/j2ee/FSI_RETAIL/applib/hibernate313.jar
     Configuration: <code-source> in /D:/product/10.1.3.1/OracleAS_3/j2ee/FSI_RETAIL/config/server.xml
This load was initiated at global.libraries:1.0 using the Class.forName() method.
The missing class is not available from any code-source or loader in the system.
     at oracle.classloader.PolicyClassLoader.handleClassNotFound(PolicyClassLoader.java:2078)
     at oracle.classloader.PolicyClassLoader.internalLoadClass(PolicyClassLoader.java:1679)
     at oracle.classloader.PolicyClassLoader.loadClass(PolicyClassLoader.java:1635)
     at oracle.classloader.PolicyClassLoader.loadClass(PolicyClassLoader.java:1620)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:164)
     at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:108)
     at org.hibernate.mapping.PersistentClass.getMappedClass(PersistentClass.java:96)
     ... 14 more

Neither, not using Oracle HTTP Server nor using JDK 1.4 incluence the behaviour of OC4J. It is your application deployment. As it should be with every Java EE server you provide an EAR file structure with modules like WAR files or EJB jar files. Each of these modules has more or less its own class loading environment.
OC4J however supports application and global shared libraries. Application shared libraries can be packaged in the EAR file using the Java EE 5 library mechanism. In essence your libraries must be known by the class loader of the Java EE module otherwise your application doesn't work.
What I need to know is what type of application (WAR, EJB, combo of both) you're using and how the files are laid out in the directory structure.
To have an example, see this blog entry: http://blogs.oracle.com/olaf/2007/07/25
--olaf

InitialContext Class Loader

Hi all,
We are experiencing a strange behaviour of the Application Class Loader. Our main issue is that if we deploy 2 applications using our code, the first application is okay, and the second application fails its loading. During the loading, we instantiate a customized InitialContextFactory (two times at all: one time per application). As a result, we have a ClassCastException in our customized InitialContext. Above a more detailed explanation of what happen. To sum up, we think that our InitialContextFactory is loaded by a master class loader, only one time for the 2 applications, and that the second application reaches the customized InitialContextFactory instantiated for the first application, so the classes loaded for the second application are not compatible.
Details:
- Each Application create a new InitialContext with the parameter "java.naming.factory.initial" equals to "com.test.CustomInitialContextFactory".
- In the class com.test.CustomInitialContextFactory we access to other code from our application, which are passed to the context factory by the environment hashtable. In the method public javax.naming.Context getInitialContext(java.util.Hashtable env), we get some parameters from the env parameter like that: CustomObject o = (CustomObject)env.get("com.test.customObject");
When the first application launches, it works very well.
When the second application launches, it fails with a ClassCastException on the class com.test.CustomObject. We think that the class com.test.CustomObject is not loaded by the good class loader so it throws a ClassCastException.
Thank you for your help

We have found how the JNDI layer builds the specified context factory:
          ClassLoader cl = (ClassLoader) AccessController.doPrivileged(
               new PrivilegedAction() {
               public Object run() {
                    return Thread.currentThread().getContextClassLoader();
But OC4J has specific Thread ClassLoader: this is the cause of all our problem. So there is a solution: create a specific context factory which calls the good class loader to load the context factory.
Bye

OC4J CLassloading Information

gday All --
Classloading questions are quite common on this forum. It's a complicated area and each container will more than likely have slightly different nuances in how it works.
We have a very good technical paper which explains general classloading and the specifics of the implementation used in OC4J available on OTN.
This document usually is able to provide answers to questions and issues that arise.
http://otn.oracle.com/tech/java/oc4j/pdf/ClassLoadingInOC4J_WP.pdf
It's a great document so I'd really like to encourage you to have a good look at it when you are thinking about class packaging, loading, etc.
I'll put a link to it on the front page of the OC4J OTN area so it's more readily accessible.
cheers
-steve-

Here is the response I got through paid support:
"There are at least 4 class loaders within OC4J:
(a) system class loader: e.g. for java.util.Date
(b) application launcher class loader: classes from oc4j.jar when oc4j is started with "java -jar oc4j.jar"
(c) server wide class loader: e.g. jar from j2ee/home/lib
(d) web app class loader: e.g. classes from WEB-INF
[They are hirarchical in some sense.]"
I assume the bean container is between c and d, but don't quote me on it.

Class loading issue in 10.1.2? commons-codec

Hi All,
I'm attempting to deploy a pretty strait forward web application (wrapped in an EAR) that includes commons-codec-1.2.jar (used by axis2). The codec jar is included in the WEB-INF\lib directory but doesn't appear to be picked (I get a NoClassDefFoundError) up unless I copy it into the ...\system\appserver\oc4j\j2ee\home\applib directory? I'm guessing this is a weird classloader issue but I can't seem to find the codec jar in another location...
I can get around the problem but I was wondering if anyone had an explanation?
Cheers,
Dan

Dan,
You need to set the search-local-classes-first attribute of element web-app-class-loader in file "orion-web.xml" to 'true' (the default is 'false') in order for OC4J to locate the "axis2" classes. Please refer to the White Paper, Classloading in OC4J (PDF):
http://www.oracle.com/technology/tech/java/oc4j/pdf/ClassLoadingInOC4J_WP.pdf
Or, if you don't like your Web browser directly opening PDF files (like I don't), there is a link to the White Paper from this Web page:
http://www.oracle.com/technology/tech/java/oc4j/index.html
Note however, that in OC4J 10.1.3 the class loading mechanisms are completely different to previous versions (including 10.1.2).
Good Luck,
Avi.

Usr/lib/mps/sercv1/libjss3.so already loaded in another classloader.

I�ve got the followindg error when i use the sun one applicationserver 7.
/usr/lib/mps/sercv1/libjss3.so already loaded in another classloader.
What can i do to solve the problem?

Hello
I had that problem more than 3 months ago on 10.1.3 DP4 "Native library already loaded in an other class loader". and I come back now, as one of my customer meets that problem himself with OC4J 10.1.3.00!
My question is the following: what sort of advices could you give, in OC4J consiguration, if one have two components run by OC4J run the same classes from the same jar file, which in turn loads a native shared library ?
Is there a way of declaring this shared library so that it is loaded only once ?
Thank you very much in advance, help very much appreciated!
Paul Barnes

Connector Class Loader in OC4J Classloader Tree

Similar Messages

Maybe you are looking for