What means class-loader delegate=

Hello:
What means <class-loader delegate="true"/> tag into sun-web.xml ?
And if the 'delegate' value is 'false' ?
Where can I find information about this property ?
Thanks a lot in advance
Best regards

Thanks.
I'm working with SUN ONE AS 7, and I found its equivalent link
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWadoc/SONEAPPSVRWEBAPP/dwdeploy.html#66152
The problem is that I have to include this tag for my WAR file for all works fine, but isn't a Web Service ( as documentation says )
This WAR calls EJB components in another server instance, being a IIOP client.
If I don't write this tag, some libraries ( Ibatis jars) have problems to load instaces dynamically ( with new Instance() ). This problem is a ClassCastException
This libraries are stored into <server-instance>/lib directory , and not into WEB-INF/lib
Indedd, if I store them into WEB-INF/lib, and not into <server-instance>/lib, same exception happens.
Classloaders are common for all server instance or every server instance has own classloaders hierarchy ?
Does anynone know why I have to delegate to parent classloader ( EJB classloader ) to find jars stored into <server-instance>/lib ?
Thanks a lot in avance
Best regards

Similar Messages

class-loader delegate="true"/

Does the above mean,
A) I will try to find every thing in my web-inf/classes, web-inf/lib directories FIRST, IF NOT FOUND, go up the chain
B) Always go up the chain, even if what I am looking for is in my web-inf/classes or web-inf/lib directories

Thanks. I may be missing some thing.
The stateless-simple application(EAR) in the samples diretory, contains a WAR and a EJB-JAR. The EJB_JAR is also inside the web-inf/lib directory of the WAR. In that scenario, why do we have <class-loader delegate="true" /> in the web-inf.xml ?
I seem to consistently get a classloader exception if I do NOT have <class-loader delegate="true" /> in the web-inf.xml!
Thanks
Sunil

WS 7.0 seemingly not honoring class-loader delegate="false"

I have a JSF web application that I ship with MyFaces jars.
I have added a sun-web.xml file in WEB-INF telling the server not to delegate class loading to its parent classloader.
However, it seems that the server chooses to use the JSF implementation that comes with the server (lib/jsf-api.jar and lib/jsf-impl.jar).
Of course, the exact same application worked perfectly with WS 6.1 (but JSF was not included in the server distribution).
Is there something I am missing?

Here is a sample index.jsp I use to determine where my classes come from.
When I type something like "javax.faces.FactoryFinder" it finds the class in
Classloader: sun.misc.Launcher$AppClassLoader@1ba34f2
URL=jar:file:/C:/soft/SunWebServer7/lib/jsf-api.jar!/javax/faces/FactoryFinder.class
This is not what I expected, since I embedded an alternate JSF implementation in my web application.
Strangely enough, when I embed, say, ant in my webapp, it's the right class that is found, not the one in the lib/ directory on the server.
Does JSF have a special status?
<%@page contentType="text/html; charset=ISO-8859-1"%>
<%@page import="java.net.URL"%>
<%@page import="java.io.ByteArrayOutputStream"%>
<%@page import="java.io.PrintStream"%>
<html>
<head>
<title>Test Sun Server 7.0</title>
</head>
<body>
Only a static text.
<br>
<form>Resource:<input type="text" name="classname"></input><br>
<input type="submit"></input><br>
</form>
<%
      String us = "<null>";
      String c = "<null>";
      try {
        c = request.getParameter("classname");
        Class cl = Class.forName(c);
        out.println("Classloader: " + cl.getClassLoader() + "<br>");
        String[] parts = c.split("\\.");
        String small = parts[parts.length - 1];
        URL u = cl.getResource(small + ".class");
        us = u.toString();
      } catch (Throwable t) {
        ByteArrayOutputStream baos = new ByteArrayOutputStream(4096);
        PrintStream o = new PrintStream(baos);
        t.printStackTrace(o);
        o.flush();
        o.close();
        us = baos.toString();
        us = us.replaceAll("\\n", "<br>");
%>
<br>
<br>
CLASS=<%=c%><br>
URL=<%=us%><br>
</body>
</html>

What is class loader?

Hai,
I am new to java. What is ment by "Class Loder" in java.
Thanks,
anil

hi,
go to http://www-128.ibm.com/developerworks/edu/j-dw-javaclass-i.html?S_TACT=105AGX02
and download the pdf file, this is a great tutorial for class loader, but you must register and log in first.
good luck
andy

What mean applet load from file system.. till now i load by browser (is

just i heard about applet load in two way
1) from net (this is throw html )
2) from local file system. (What is this )
plszz

from local file system. (What is this )When the html file and the applet is on your harddisk and you open the html file in a browser.

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

SJSAS 8.2 EJB class loader

Hello,
I did not found how to set the class loader to parent last for EJBs.
I have an EAR with a WAR and 2 EJBs, for the WAR I've added :
<class-loader delegate="false"/>in the sun-web.xml descriptor, but I don't know how to do it in my JARs.
I think I have a conflict between the Xerces version used by Sun AS and the one embbeded in my EAR.
Any advice ?

The servlet specs recommends that the web class loader looks locally before delegating it to the parent. Thus there is a provision of a paramenter which can be configured.
Did u try putting it ib by editing the classpath-suffix attribute of the java-config element in the domain.xml file. But now this will be available to all the applicatuons across the domain.

What is a class loader

What is a class loader in java? Is this related to JVM?

Don't double post the same question. I've removed the thread you started in the Java Virtual Machine (JVM) forum.
db

What means the " E " in class Vector and " T " in class Class?

Hi world!
I was searching in the java docs and in the source code of Java and found a syntaxis that I don't know what mean. This:
public class Vector<E>
    extends AbstractList<E>
    implements List<E>, ...and this:
public Vector(Collection<? extends E> c)this too:
public final
    class Class<T> impleme...and that:
public static Class<?> forName(String className) well you get the idea. If someone could give me where can I find information about the using of this.
Tanks

See the generics tutorial:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

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

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!

System class loader vs application class loader

Hello
I have a class that uses a third partyjar which I have put in /jre/lit/ext. The class compiles but fails at runtime being unable to read the property files called in the class' constructor. I believe that is b/c the third party jars are loading w/ the system class loader and cannot "see" the property files "floating" at the same level as the class that is calling them.
So I created a jar, of the property files, with the same directory/package structure as the location of the property files and put that in the /jre/lib/ext and STILL the same problem; cannot read the property files, the constructor fails, fugly. There is an overloaded constructor that includes a parameter for the property files, but I need to get this to work as is first. What am I missing? Please edify me. tia.

If the 3rd party jar needs a certain properties file to initialize correctly, I doubt it would be looking for it in the class hierarchy. I mean I doubt it does:
Properties p = new Properties();
p.load( getClass().getResourceAsStream() );It's more likely to do:
Properties p = new Properties();
p.load( new FileInputStream(...) );The reason is that the property file should be easily edited by the user and users know how to move around in the file system, not in the Java jars and classpaths.
Just a guess...

Transient / network class loader

i hope to understand exactly what "transient" means in the context of remote class loading.
i am serializing an object on a local machine.
send it over a socket to remote machine.
remote machine de-serializes.
it needs the classes to de-serialize.
calls back to the local machine.
gets the classes.
ok.
issue:
i am looking at the classes that the { java.io.ObjectInputStream "resolveClass(ObjectStreamClass desc);" }
is requesting for loading during the de-serialization process.
and see that the classes for the objects that i marked as "transient" are still being requested.
i did not expect this.
my marking objects as "transient" means those objects are not a part of an object's persistent "state".
yet, the classes for the transient objects are still requested.
do i not understand transient?

i hope to understand exactly what "transient" means in the context of remote class loading.The context is irrelevant. 'transient' has the same meaning in all contexts. It means the field(s) so marked is/are ignored by Java Serialization.
and see that the classes for the objects that i marked as "transient" are still being requested.By the class loader. The class loader doesn't care about 'transient'. The receiver will still need those classes if it uses that field. The class loader can't assume that it won't do that. So it loads the classes of the transient objects. Just like it loads the superclasses, and the classes of all the other fields, member and static.

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

What means class-loader delegate=

Similar Messages

Maybe you are looking for