Class loading for webservice endpoint

Hi,
I have developed a simple pojo webservice endpoint(jax-rpc) and deployed it in jboss app server. In the endpoint i have a static block which is getting executed every time a client invokes this webservice.Dose this means everytime the webservice is invoked the container loads the class again?Is this behavior specific to jboss or is it true for all app servers?
any info/pointers on this will be very helpful.
Regards,
comfortably_numb

I guess the solution could be the CLASSPATH. If this is the case, then Can anyone tell me how to set CLASSPATH through java program itself (if the program knows the directory structure) . Actually, there is a whole application running in WebLogic8, and I want to set the CLASSPATH at runtime through java program.
Any help?
Thanks,
Sumit

Similar Messages

How can I make server use single class loader for several applications

I have several web/ejb applications. These applications use some common libraries and should share instances of classes from those libraries.
But applications are being deployed independently thus packaging all them to EAR is not acceptable.
I suppose the problem is that each application uses separate class loader.
How can I make AS use single class loader for a set of applications?
Different applications depend on different libraries so I need a way that will not share library for all applications on the domain but only for some exact applications.
When I placed common jar to *%domain%/lib* - all works. But that jar is shared between all applications on the domain.
When I tried to place common jar to *%domain%/lib/applibs* and specified --libraries* attribute on deploying I got exception
java.lang.ClassCastException: a.FirstDao cannot be cast to a.FirstDaoHere http://download.oracle.com/docs/cd/E19879-01/820-4336/6nfqd2b1t/index.html I read:
If multiple applications or modules refer to the same libraries, classes in those libraries are automatically shared.
This can reduce the memory footprint and allow sharing of static information.Does it mean that classes should be able to be casted ?

You didn't specify which version of the application server you are using, but the config is similar as long as you know what to look for. Basically, you need to change the classloader delegation. Here's how it is done in 8.2
http://download.oracle.com/docs/cd/E19830-01/819-4721/beagb/index.html

Why do we use only dynamic class loading for JDBC drivers

Hi,
My JDBC experience is that we always use dynamic class loader for drivers.
If we have a well defined package from a vendor, why do we use this dynamic class loading feature for drivers??

chandunitw wrote:
Hi,
My JDBC experience is that we always use dynamic class loader for drivers.
If we have a well defined package from a vendor, why do we use this dynamic class loading feature for drivers??Oftentimes, the driver class name is set in a configuration file, not in code. So the thing which processes the configuration file has no idea ahead of time which driver or drivers it will support, so it is not coded specifically for any. So it loads the driver by reflection, since it is given the class name as a string it can use with the reflection API.

Class Loader for Jar Files

I have a set of Jar files which i need to load using Custom Class Loader. Any one who has Javacode for Custom Class Loader for loading Jar files send it. The Jar files are local jar files.

Here is the class loader I use:
import java.net.URL;
import java.net.URLClassLoader;
import java.net.JarURLConnection;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.lang.reflect.InvocationTargetException;
import java.util.jar.Attributes;
import java.io.IOException;
* A class loader for loading jar files, both local and remote.
public class JarClassLoader extends URLClassLoader {
    private URL url;
    private URL[] m_urlList = new URL[10];
     * Creates a new JarClassLoader for the specified url.
     * @param url the url of the jar file
    public JarClassLoader(URL url,ClassLoader cl) {
         super(new URL[] { url },cl);
      this.url = url;
    public JarClassLoader(URL[] urlList,ClassLoader cl) {
         super( urlList,cl);
      this.m_urlList = urlList;
     * Returns the name of the jar file main class, or null if
     * no "Main-Class" manifest attributes was defined.
    public String getMainClassName() throws IOException {
      URL u = new URL("jar", "", url + "!/");
         JarURLConnection uc = (JarURLConnection)u.openConnection();
         Attributes attr = uc.getMainAttributes();
         return attr != null ? attr.getValue(Attributes.Name.MAIN_CLASS) : null;
     * Invokes the application in this jar file given the name of the
     * main class and an array of arguments. The class must define a
     * static method "main" which takes an array of String arguemtns
     * and is of return type "void".
     * @param name the name of the main class
     * @param args the arguments for the application
     * @exception ClassNotFoundException if the specified class could not
     *            be found
     * @exception NoSuchMethodException if the specified class does not
     *            contain a "main" method
     * @exception InvocationTargetException if the application raised an
     *            exception
     public void invokeClass(String name, String[] args) throws ClassNotFoundException,
            NoSuchMethodException,
            InvocationTargetException
         Class c = loadClass(name);
         Method m = c.getMethod("main", new Class[] { args.getClass() });
         m.setAccessible(true);
         int mods = m.getModifiers();
         if (m.getReturnType() != void.class || !Modifier.isStatic(mods) || !Modifier.isPublic(mods)) {
         throw new NoSuchMethodException("main");
         try {
           m.invoke(null, new Object[] { args });
         } catch (IllegalAccessException e) {
         // This should not happen, as we have disabled access checks
}

Class Loader Hierarchy in Weblogic 7.0

I have read the BEA documentation on the class loader hierarchy in Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several utility jars. The
web apps' manifests contain the Class-Path entry for the utility jars. My understanding
of this is that each web app SHOULD have its own class loader. Also, the utility
jars will be scoped in a separate class loader and WILL NOT have visibility to
the web app classes. The web app classes should have visibility to the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the class loader
for each servlet when it was loaded. I also printed the class loader from a class
that is DEFINITELY contained in one of the utility jars. Here is the result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Utility Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders (i.e. one
for each class above). I believe the above printout says that all 3 classes are
being loaded by the SAME class loader instance (Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on?

I rechecked the classpath for the user that starts Weblogic, and in the classpath
I found the project "src" directory (must have missed it earlier). When we did
our build, the classes are placed in the src structure then copied to the build
area. That's the reason I was not seeing the appropriate class loader hierarchy.
Thanks for all of the comments.
"Sanjeev Chopra" <[email protected]> wrote:
>
"Mark Cotherman" <[email protected]> wrote in message
news:[email protected]...
Thanks for your comments again Mark. I'm just trying to get a goodhandle
on how
this is working.
I'll assume that somehow my web app classes are being loaded into theroot
classloader.
The next question is... why??Just to be sure - is there any way these classes are sneaking into the
system classpath ?
My ear file contains the following:
a.war
b.war
c.war
lib/util1.jar
lib/util2.jar
lib/util3.jar
lib/util4.jar
The manifest in all three wars reference all util jars. This ear deployssuccessfully
on Weblogic with no errors.
How could these separate servlets (one in each war) not have seperateclass loaders
seperate from the root where the utils should reside. I don't thinkthat
I have
any control over where Weblogic loads the war classes, or do I?
See comments below....
Mark Spotswood <[email protected]> wrote:
Mark Cotherman wrote:
Thanks for the follow-up.
I want to make sure I follow what you are saying. All classes in
the
manifest
Class-Path of WARs are exported to the parent classloader.That's right.
To me this is the correct behavior since the manifest Class-Path
is
meant to provide
a way to share common utility classes among several web apps. AllEJB jars and
manifest Class-Path entries should be loaded by the same class loader.Its a way to share class definitions, but not necessarilly class
instances. I don't think that a web application should be extending
the classpath of its parent's classloader. This leads to namespace
problems as well as reloadability issues.
Ok, you lost me here. Shouldn't delegation handle the namespacecollisions??
If the web app class loader has a class definition (webapp:com.xyz.ClassA) with
exactly the same name in the same package as the root class loader(rootloader:
com.xyz.ClassA), I thought the web app would use (delegate loading)the
class
definition from the root class loader when PreferWebInf is set to false.
Isn't this why the PreferWebInf attribute, when set to true, can causeClassCastExceptions??
The web app when creating an instance of (webapp: com.xyz.ClassA)from
the web
app class loader can potentially pass a reference to this instanceto a
class
instance loaded from the root loader. The root class loader has adifferent class
definition for ClassA.
REALLY what makes since is that all common jar files be defined
in
the manifest
Class-Path OF THE ear FILE (if the WAR(s) are in an ear). These
jar
files should
then be loaded by the same class loader as the EJB jars. There shouldbe no need
for the WARs to have any reference to the utility jars since the
EJB
class loader
is the parent of the WAR class loaders.The ear file doesn't have a manifest classpath, but what you are getting
at makes sense. If you add a manifest to any EJBs in your app, theall
webapps (as well as all other EJBs) will be able to see it, sincewith
our structure, EJBs are loaded into the application's root classloader.
My problem is that the ACTUAL SERVLET classes are NOT being loadedby a separate
class loader from the EJB and common jar class loader. This is
completely
against
what is being said in the Weblogic documentation. The Manifest
Class-Path
should
have nothing to do with where the classes that reside in
WEB-INF/classes
of my
servlet are loaded.Classloaders will ask their parent for the class first before loading
it
themselves. So if the parent classloader somehow has visibility to
classes that your webpapp references, then it will get loaded by the
parent classloader.
I am in the middle of migrating an app from an older version of
Weblogic,
and
it would be helpful to have the ACTUAL class loading hierarchy welldocumented.
The basic hierarchy is all EJBs are in a root shared classloader and
each web application is loaded by a classloader that is a child of
that root.
Again, am I missing something here???My suspicion is that somehow these servlets are in the classpath ofthe
root classloader, so when the webapp classloaders delegate to thatone,
it will come up with the class.
mark
Mark Spotswood <[email protected]> wrote:
I believe what you are seeing is a bug in the servlet container.
The classloader organization is what you expect, but each webapp
is exporting the classpath information from its manifest to the
classloader above its classloader (which is common to all
three webapps) rather than to its own classloader. So because
of the delegation that happens with classloading, the common
parent classloader is the one that loads the class.
I believe that this behavior exists as an attempt to avoid
ClassCastExceptions, but I don't think that it is the right
solution to this problem. In our 8.1 release, this behavior
has been changed. That is, web applications no longer export
manifest classpath information to the parent of their classloader.
This change has not been ported back to the 7.x line, but a bug
report has been created (CR099889). You should be able to follow
up with support with this CR number.
mark
Mark Cotherman wrote:
I have read the BEA documentation on the class loader hierarchy
in
Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several
utility
jars. The
web apps' manifests contain the Class-Path entry for the utility
jars.
My understanding
of this is that each web app SHOULD have its own class loader.
Also,
the utility
jars will be scoped in a separate class loader and WILL NOT have
visibility
to
the web app classes. The web app classes should have visibility
to
the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the
class
loader
for each servlet when it was loaded. I also printed the class loaderfrom a class
that is DEFINITELY contained in one of the utility jars. Here is
the
result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04
Utility
Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders(i.e. one
for each class above). I believe the above printout says that all
3
classes are
being loaded by the SAME class loader instance
(Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on?

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!

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 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

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:33 PM

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:33 PM

Replacing system class loader

Hi!
I'm trying to replace the system class loader for plugin management reasons. I've written a simple test app for testing, but it doesn't work. The first code is a ClassLoader, the second is the main code.
I try to run the code like this: java -Xbootclasspath/a:. -Djava.system.class.loader=A -cp . B
It uses my classloader every time, except for when I call Class.forName(). What could be the problem?
Thanks, Bal�zs
public class A extends java.lang.ClassLoader {
public A(ClassLoader parent) {
super(parent);
System.out.println("A loaded, parent is " + parent);
public Class loadClass(String name) throws java.lang.ClassNotFoundException {
try {
Class c = getParent().loadClass(name);
System.out.println("A was asked for " + name + " and delegated it to " + getParent());
return c;
} catch (ClassNotFoundException e) {
System.out.println("A was asked for " + name + " but didn't find it");
throw new ClassNotFoundException(name + " not found :[");
}; // ENDOF CLASS A
public class B {
public static void main(String[] args) {
(new B()).proc();
private void proc() {
System.out.println("Hello World!");
System.out.println("Class loader: " + getClass().getClassLoader());
try {
Class.forName("C");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}; // ENDOF CLASS B

Thanks for the reply. I think I've got a much better idea of how this stuff works now. I think what I need to do is register my deserializer with SOAP as a class that will really load the deserializer using Class.forName() with my class loader as a parameter. Then when the bootstrap class loader can't find a class, findClass() in my classloader will be called and I can load it from a URL.
Should work.
Thanks very much!

Spacename of a class loader

Question:
Does a class loader stores references for any class loaded by its parents after a request from itself to load a class? In this way the set of classes loaded for a class loader and the returned ones by its parent after a request would comprise the spacename of this class loader.

i think so. the class loader if unable to load the class actually asks its parent class loader to load the class (since its a parent delegation model) and thus acts as the initiating class loader for that type. Thus it adds the type name to the list maintained by it. Next time when the type is referenced, it first check this list (its namespace) and and if it finds it, it loads it otherwise it delegates it to its parent.
G.P.

RMI and the class loader delegation model

Hello,
I need to know what the class loader delagation chain looks like when RMI does dynamic class loading. What is the RMIClassLoader's parent? Does it delegate to Thread.currentThread().getContextClassLoader()?
In a test application I can debug the chain which looks like this:
sun.misc.Launcher$AppClassLoader@bac748
sun.misc.Launcher$ExtClassLoader@7172ea
The AppClassLoader is the class loader for the test and is coincident with getSystemClassLoader(). Its parent is the ExtClassLoader which I believe is in charge of loading anything from jre/lib/ext. But I don't know how to get a reference to the RMIClassLoader in order to find out what it's parent is.
I would appreciate any info on this.
Thanks in advance,
Joe

Well that was easy.
I just used the RMIClassLoader.getClassLoader(String codebase) and was able to determine the chain.
FYI: the chian is as follows:
ExtClassLoader <-- AppClassLoader <-- sun.rmi.server.LoaderHandler
Of interest, if you have a custom class loader its parent will most likely be the AppClassLoader but the rmi class loader will not chain off of your custom class loader. It does some interesting things in order for this to work. It will look for custom class loader to load interfaces but will use the RMIClassLoader to load stubs. Pretty cool.
Thanks anyway.
Joe

Help! -- different class loader issue

From within an EJB I am trying to cast a serializable object, that was passed into this EJB, to its original type. The process ended with a ClassCastException, even though I have double checked that the object being casted is of the correct type and fully qualified package path. It turns out that the problem is caused by the involvment of 2 different class loaders -- The class loader that loads the object is not the same one that loads the EJB doing the casting. The thing that confuses me the most is that this program used to work fine without the exception when it was running in an older environment. Is this a VM issue? Do we have control over what class loader to use when load certain classes/objects? What's the fix to the problem?
Please help!
Thanks in advance.
Lifeng

It is a Java platform version issue. Since Java 2 The classloaders are lay out in a hierarchy. You can read about it in the public chapters of the book "Inside the Java 2 Virtual Machine" by Bill Venners at
www.artima.com
This may be helpful for you . It specifies the class loaders used by a thread to load subsequent classes: aThread.setContextClassLoader(aClassLoader)
Other soulution is to have the object and EJB being loaded by the same class loader, which could be a common parent class loader for the ones that in your code are actually asked to load these objects
Otherwise, java.lang.reflect can deal with objects whose type is not known by the compiler.

Design patterns for Dynamic Class Loading

Hi,
I have to develop a program for uni that dynamically loads classes based on names in a text file. All the classes subclass an abstract class with a constructor that takes one argument. This means I can't use the Class.forName(className).newInstance() method of class loading. I have researched some design patterns I could use and have come up with the following 3:
Factory pattern; "Robocode" pattern (not it's real name, but Robocode uses it); and, the "one I made up myself" pattern.
The robocode pattern instantiates a class using the default no-argument constructor then immediately sets all properties that shoud have been provided in the constructor:
Object o = Class.forName(myClass).newInstance();
o.setProperty(property);Personally I think this is ugly and a cheap fix instead of doing it properly.
My own pattern finds the constructor that takes the arguments I need then calls it to create the object:
Class c = Class.forName(myClass);
Constructor cons = c.getConstructor(new Class[]{Class.forName("java.lang.String")});
Object o = cons.newInstance(new Object[]{"hello"});What's the best to use? Are there any other patterns I should consider?

My own pattern finds the constructor that takes the
arguments I need then calls it to create the object:
Class c = Class.forName(myClass);
Constructor cons = c.getConstructor(new
Class[]{Class.forName("java.lang.String")});
Object o = cons.newInstance(new Object[]{"hello"});
I have followed this basic 'pattern' several times though I would use
Constructor cons = c.getConstructor(new Class[]{String.class});
It works great.

How to improve class-loading performance for missing classes

Hi,
do you have any ideas how we can improve the class-loading performance on a weblogic 12c running on jrockit? We spend about 20-30 ms per request in class-loading due to the way hibernate criteria API works (it tries to load quite a lot of missing classes). The only thing I came up with was to invert the class-loading using the weblogic descriptor for those missing classes (which are actually no real classes but some parts of a generated JPQL) which does improve performance a bit.
Thanks
Dimo

Hi,
do you have any ideas how we can improve the class-loading performance on a weblogic 12c running on jrockit? We spend about 20-30 ms per request in class-loading due to the way hibernate criteria API works (it tries to load quite a lot of missing classes). The only thing I came up with was to invert the class-loading using the weblogic descriptor for those missing classes (which are actually no real classes but some parts of a generated JPQL) which does improve performance a bit.
Thanks
Dimo

Class loading for webservice endpoint

Similar Messages

Maybe you are looking for