Weblogic Class Loader caching/writing classes to weblogic/myServer/classfiles

It seems that if I compile a class that a JSP uses while Weblogic is
          running, Weblogic's class loader has this nasty habit of caching/writing
          the class that already has loaded into memory into:
          weblogic/myServer/classfiles
          Weblogic then refers to the older class file under the above directory
          when the server is started again. Is there any way to turn this "class
          loader caching" off in Weblogic? Thanks!
          -hjk

You have to tell WLAS where to load your new classes. You can change
          workingDir of your JSP configuration in weblogic.properties to point to your
          new class directory.
          Cheers - Wei
          Hyung-Jin Kim <[email protected]> wrote in message
          news:[email protected]..
          > It seems that if I compile a class that a JSP uses while Weblogic is
          > running, Weblogic's class loader has this nasty habit of caching/writing
          > the class that already has loaded into memory into:
          >
          > weblogic/myServer/classfiles
          >
          > Weblogic then refers to the older class file under the above directory
          > when the server is started again. Is there any way to turn this "class
          > loader caching" off in Weblogic? Thanks!
          >
          > -hjk
          >

Similar Messages

Is it possible clear the class loader cache programatically?

Hi,
Is it possible clear the class loader cache programatically?
Thanks

By the cache do you mean the loaded classes? If so, you can do that by discarding any pointer you have to the class loader and creating a new class loader. ...though I wonder why you would need to do that...

SOA WebLogic : Cannot load JDBC driver class

Hi, I'm new to this Oracle SOA World. Currently I'm trying to configure environment on my system. I found a very useful document to install all related SOA component to my system, the document name was 'Quick Start Guide for Oracle® SOA Suite 11gR1 (11.1.1.5.0)'. I did all the steps written in the document and have installed all the components successfully, component including Database, Jdevelper, WebLogic Server, RCU, SOA suite, service bus, all are installed successfully.
But when I'm trying to Configure Application Server (start -> Oracle SOA 11g-Home1), at one step 'Configure JDBC Component Schema' , here I'm getting this message
* The driver class listed below was not found in product installation
vendor: Derby
Driver: org.apache.derby.jdbc.clientdriver
A Test will not be performed on any database connections using this driver
In addition, when i just ignore this message and continue installation, after installation when i run weblogic server then it gives error and gets terminated
here is weblogic server log:
* To start WebLogic Server, use a username and *
* password assigned to an admin-level user. For *
* server administration, use the WebLogic Server *
* console at http:\\hostname:port\console *
starting weblogic with Java version:
Listening for transport dt_socket at address: 8453
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b50)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode)
Starting WLS with line:
C:\Oracle\MIDDLE~1\JDK160~1\bin\java -client -Xdebug -Xnoagent -Xrunjdwp:transpo
rt=dt_socket,address=8453,server=y,suspend=n -Djava.compiler=NONE -Xms512m -Xmx
1024m -XX:PermSize=128m -XX:MaxPermSize=512m -Dweblogic.Name=AdminServer -Djava.
security.policy=C:\Oracle\MIDDLE~1\WLSERV~1.3\server\lib\weblogic.policy -Xveri
fy:none -Xverify:none -da:org.apache.xmlbeans... -ea -da:com.bea... -da:javeli
n... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbcons
ole... -Dplatform.home=C:\Oracle\MIDDLE~1\WLSERV~1.3 -Dwls.home=C:\Oracle\MIDDLE
~1\WLSERV~1.3\server -Dweblogic.home=C:\Oracle\MIDDLE~1\WLSERV~1.3\server -Dcom
mon.components.home=C:\Oracle\MIDDLE~1\ORACLE~1 -Djrf.version=11.1.1 -Dorg.apach
e.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger -Ddomain.home=
C:\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2 -Djrockit.optfile=C:\Oracle\MIDDLE~
1\ORACLE~1\modules\oracle.jrf_11.1.1\jrocket_optfile.txt -Doracle.server.config.
dir=C:\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2\config\FMWCON~1\servers\AdminSe
rver -Doracle.domain.config.dir=C:\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2\con
fig\FMWCON~1 -Digf.arisidbeans.carmlloc=C:\Oracle\MIDDLE~1\USER_P~1\domains\BAS
E_D~2\config\FMWCON~1\carml -Digf.arisidstack.home=C:\Oracle\MIDDLE~1\USER_P~1\
domains\BASE_D~2\config\FMWCON~1\arisidprovider -Doracle.security.jps.config=C:\
Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2\config\fmwconfig\jps-config.xml -Dorac
le.deployed.app.dir=C:\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2\servers\AdminSe
rver\tmp\_WL_user -Doracle.deployed.app.ext=\- -Dweblogic.alternateTypesDirector
y=C:\Oracle\MIDDLE~1\ORACLE~1\modules\oracle.ossoiap_11.1.1,C:\Oracle\MIDDLE~1\O
RACLE~1\modules\oracle.oamprovider_11.1.1 -Djava.protocol.handler.pkgs=oracle.md
s.net.protocol"|"oracle.fabric.common.classloaderurl.handler"|"oracle.fabric.com
mon.uddiurl.handler"|"oracle.bpm.io.fs.protocol -Dweblogic.jdbc.remoteEnabled=f
alse -da:org.apache.xmlbeans... -Dsoa.archives.dir=C:\Oracle\Middleware\Oracle_
SOA1\soa -Dsoa.oracle.home=C:\Oracle\Middleware\Oracle_SOA1 -Dsoa.instance.home=
C:\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~2 -Dtangosol.coherence.clusteraddress
=227.7.7.9 -Dtangosol.coherence.clusterport=9778 -Dtangosol.coherence.log=jdk -D
javax.xml.soap.MessageFactory=oracle.j2ee.ws.saaj.soap.MessageFactoryImpl -Dwebl
ogic.transaction.blocking.commit=true -Dweblogic.transaction.blocking.rollback=t
rue -Djavax.net.ssl.trustStore=C:\Oracle\MIDDLE~1\WLSERV~1.3\server\lib\DemoTrus
t.jks -Dem.oracle.home=C:\Oracle\Middleware\oracle_common -Djava.awt.headless=tr
ue -Dums.oracle.home=C:\Oracle\Middleware\Oracle_SOA1 -Dweblogic.management.disc
over=true -Dwlw.iterativeDev= -Dwlw.testConsole= -Dwlw.logErrorsToConsole= -Dwe
blogic.ext.dirs=C:\Oracle\MIDDLE~1\patch_wls1035\profiles\default\sysext_manifes
t_classpath;C:\Oracle\MIDDLE~1\patch_jdev1111\profiles\default\sysext_manifest_c
lasspath weblogic.Server
Listening for transport dt_socket at address: 8453
<2012-mar-02 kl 21:14 CET> <Info> <Security> <BEA-090905> <Disabling CryptoJ JCE
Provider self-integrity check for better startup performance. To enable this ch
eck, specify -Dweblogic.security.allowCryptoJDefaultJCEVerification=true>
<2012-mar-02 kl 21:14 CET> <Info> <Security> <BEA-090906> <Changing the default
Random Number Generator in RSA CryptoJ from ECDRBG to FIPS186PRNG. To disable th
is change, specify -Dweblogic.security.allowCryptoJDefaultPRNG=true>
<2012-mar-02 kl 21:14 CET> <Info> <WebLogicServer> <BEA-000377> <Starting WebLog
ic Server with Java HotSpot(TM) Client VM Version 19.1-b02 from Sun Microsystems
Inc.>
<2012-mar-02 kl 21:14 CET> <Info> <Management> <BEA-141107> <Version: WebLogic S
erver 10.3.5.0 Fri Apr 1 20:20:06 PDT 2011 1398638 >
<2012-mar-02 kl 21:14 CET> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to STARTING>
<2012-mar-02 kl 21:14 CET> <Info> <WorkManager> <BEA-002900> <Initializing self-
tuning thread pool>
<2012-mar-02 kl 21:14 CET> <Notice> <Log Management> <BEA-170019> <The server lo
g file C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServe
r\logs\AdminServer.log is opened. All server side log events will be written to
this file.>
<2012-mar-02 kl 21:14 CET> <Notice> <Security> <BEA-090082> <Security initializi
ng using security realm myrealm.>
<2012-mar-02 kl 21:14 CET> <Warning> <oracle.as.jmx.framework.MessageLocalizatio
nHelper> <J2EE JMX-46041> <The resource for bundle "oracle.jrf.i18n.MBeanMessage
Bundle" with key "oracle.jrf.JRFServiceMBean.checkIfJRFAppliedOnMutipleTargets"
cannot be found.>
<2012-mar-02 kl 21:14 CET> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to STANDBY>
<2012-mar-02 kl 21:14 CET> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to STARTING>
<2012-mar-02 kl 21:15 CET> <Critical> <JTA> <BEA-110482> <A logging last resourc
e failed during initialization. The server cannot boot unless all configured log
ging last resources (LLRs) initialize. Failing reason:
weblogic.common.resourcepool.ResourceSystemException: Cannot load driver class:
org.apache.derby.jdbc.ClientDriver
weblogic.common.resourcepool.ResourceSystemException: Cannot load driver class:
org.apache.derby.jdbc.ClientDriver
at weblogic.jdbc.common.internal.JDBCUtil.parseException(JDBCUtil.java:3
01)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.loadDriver(Connect
ionEnvFactory.java:75)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.<init>(ConnectionE
nvFactory.java:131)
at weblogic.jdbc.common.internal.ConnectionPool.initPooledResourceFactor
y(ConnectionPool.java:712)
at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.
java:235)
Truncated. see log file for complete stacktrace
>
<2012-mar-02 kl 21:15 CET> <Error> <Deployer> <BEA-149205> <Failed to initialize
the application 'wlsbjmsrpDataSource' due to error weblogic.application.ModuleE
xception: .
weblogic.application.ModuleException:
at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:302)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modu
leListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Depl
oymentCallbackFlow.java:517)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineD
river.java:52)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Dep
loymentCallbackFlow.java:159)
Truncated. see log file for complete stacktrace
Caused By: weblogic.common.resourcepool.ResourceSystemException: Cannot load dri
ver class: org.apache.derby.jdbc.ClientDriver
at weblogic.jdbc.common.internal.JDBCUtil.parseException(JDBCUtil.java:3
01)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.loadDriver(Connect
ionEnvFactory.java:75)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.<init>(ConnectionE
nvFactory.java:131)
at weblogic.jdbc.common.internal.ConnectionPool.initPooledResourceFactor
y(ConnectionPool.java:712)
at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.
java:235)
Truncated. see log file for complete stacktrace
>
<2012-mar-02 kl 21:16 CET> <Alert> <OSB Security> <BEA-387068> <There is no PKI
credential mapper provider configured in your security realm. Service key provid
er management will be disabled. Configure a PKI credential mapper provider if yo
u need service provider support. This is typically the case if you have Oracle S
ervice Bus proxy services with web service security enabled or outbound 2-way SS
L connections.>
<2012-mar-02 kl 21:16 CET> <Warning> <Coherence> <BEA-000000> <Oracle Coherence
3.6.0.4 (member=n/a): Local address "127.0.0.1" is a loopback address; this clus
ter node will not connect to nodes located on different machines>
<2012-mar-02 kl 21:17 CET> <Warning> <J2EE> <BEA-160140> <Unresolved optional pa
ckage references (in META-INF/MANIFEST.MF): [Extension-Name: oracle.applcore.mod
el, Specification-Version: 0.1, Implementation-Version: 11.1.1.0.0, referenced f
rom: C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\
tmp\_WL_user\usermessagingserver\a7bt7z]. Make sure the referenced optional pack
age has been deployed as a library

Hi:
try placing the jars that represent ur driver, here
For both Windows and Linux, you must perform the following steps:
Drop the vendor-specific driver JAR files to the user_projects/domains/soainfra/lib directory.
Drop the vendor-specific driver JAR files to the <Weblogic_Home>/server/lib.
Edit the classpath to include the vendor-specific jar file in <Weblogic_HOME>/common/bin/commEnv.sh
This info was copied, from here: http://docs.oracle.com/cd/E21764_01/integration.1111/e10231/adptr_db.htm#CHDBEJDC
Hope this helps
best

Class loader & cache

Hi!
I have developed an application that use CLASS LOADER methods to download classes when needed in the application.
I would like to know if there exist any way to use a JRE cache for using these classes and download it when it changes.
Thank you very much for any help!
Jose Monzon.

Hi,
Class is put into the cache of the class loader in the
defineClass() method and may be retrieved from the cache with the findLoadedClass() method.
Check the above methods for caching.
I hope this helped.
Roopasri Vittal
Developer Technical Support
Sun Microsystems
http://sun.com/developers/support

Can I set Boot class loader or system class loader?

In my application, there are classes in a jar files, all these files in the jar need be loaded by a ClassLoader in my application.
And the classes out of jar do not need the ClassLoader to load. the structure is like :
-----myapp.jar ------in this jar, all classes need be loaded by a specified ClassLoader
|---anoapp ------classes in this package, is normal classes
|-------|----a.class
|----b.class
| ----other classes
but my a.class need to access a class in myapp.jar, so I load the class use my ClassLoader, but there still occur
**********ClassFormatError : bad magic number**************
I print the classloader in a.class
+---- System ClassLoader is : com.sun.misc.Launcher$AppClassLoader    ------------it is not my ClassLoader
+---- a.class.getClassLoader is same as System ClassLoader    -------------------it still is not my ClassLoader
+---- Thread.currentThread().getContextClassLoader          ------------------ it is my ClassLoader
So I think when I access class in myapp.jar, it will loaded by System ClassLoader or Bootstrap ClassLoader, if I can set one these two classloader as my ClassLoader, it maybe not occur the Error,
But There are not obvious method in System or Runtime etc.
1. So can Set System Classloader or Bootstrap ClassLoader?
2. If not, How can solve my problem?
Thands in advanced!

**********ClassFormatError : bad magic number**************If you get that error, then no classloader will help you. This is a problem with your running code meant for a newer version of the Virtual Machine in an older version.
Looks like you're compiling the code with a recent JDK (1.4.x?), but running with an older VM. Try just typing "java -version" and see what it prints.
This should just be a matter of running with the right VM. If this is an applet you're trying to run inside the browser, make sure that the browser is using the right VM. Run the "Java Control Panel" and select the correct version.

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

Custom class loader and local class accessing local variable

I have written my own class loader to solve a specific problem. It
seemed to work very well, but then I started noticing strange errors in
the log output. Here is an example. Some of the names are in Norwegian,
but they are not important to this discussion. JavaNotis.Oppstart is the
name of my class loader class.
java.lang.ClassFormatError: JavaNotis/SendMeldingDialog$1 (Illegal
variable name " val$indeks")
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at java.lang.ClassLoader.defineClass(ClassLoader.java:431)
at JavaNotis.Oppstart.findClass(Oppstart.java:193)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at JavaNotis.SendMeldingDialog.init(SendMeldingDialog.java:78)
at JavaNotis.SendMeldingDialog.<init>(SendMeldingDialog.java:54)
at JavaNotis.Notistavle.sendMelding(Notistavle.java:542)
at JavaNotis.Notistavle.access$900(Notistavle.java:59)
at JavaNotis.Notistavle$27.actionPerformed(Notistavle.java:427)
JavaNotis/SendMeldingDialog$1 is a local class in the method
JavaNotis.SendMeldingDialog.init, and it's accessing a final local
variable named indeks. The compiler automatically turns this into a
variable in the inner class called val$indeks. But look at the error
message, there is an extra space in front of the variable name.
This error doesn't occur when I don't use my custom class loader and
instead load the classes through the default class loader in the JVM.
Here is my class loading code. Is there something wrong with it?
Again some Norwegian words, but it should still be understandable I hope.
     protected Class findClass(String name) throws ClassNotFoundException
         byte[] b = loadClassData(name);
         return defineClass(name, b, 0, b.length);
     private byte[] loadClassData(String name) throws ClassNotFoundException
         ByteArrayOutputStream ut = null;
         InputStream inn = null;
         try
             JarEntry klasse = arkiv.getJarEntry(name.replace('.', '/')
+ ".class");
             if (klasse == null)
                throw new ClassNotFoundException("Finner ikke klassen "
+ NOTISKLASSE);
             inn = arkiv.getInputStream(klasse);
             ut = new ByteArrayOutputStream(inn.available());
             byte[] kode = new byte[4096];
             int antall = inn.read(kode);
             while (antall > 0)
                 ut.write(kode, 0, antall);
                 antall = inn.read(kode);
             return ut.toByteArray();
         catch (IOException ioe)
             throw new RuntimeException(ioe.getMessage());
         finally
             try
                if (inn != null)
                   inn.close();
                if (ut != null)
                   ut.close();
             catch (IOException ioe)
     }I hope somebody can help. :-)
Regards,
Knut St�re

I'm not quite sure how Java handles local classes defined within a method, but from this example it seems as if the local class isn't loaded until it is actually needed, that is when the method is called, which seems like a good thing to me.
The parent class is already loaded as you can see. It is the loading of the inner class that fails.
But maybe there is something I've forgotten in my loading code? I know in the "early days" you had to do a lot more to load a class, but I think all that is taken care of by the superclass of my classloader now. All I have to do is provide the raw data of the class. Isn't it so?

Weblogic Class Loader issues.

Hi all!
Let me explain my problem.
I have an EJB which has in its same Java package some support classes
& also a startup class. I created an EJB jar file (containing the home,
remote, bean, the deployment descriptors & the container generated stubs)
for deployment. I also compiled all the support classes & the startup class
into the /weblogic/myserver/serverclasses directory. I also added the
required entries in the weblogic.properties file for the startup class.
Now the problem is that the support classes & the startup class contain
methods & constructors which have package level access (i.e the default
access in Java). At runtime, when my bean tries to access one of these
methods, an IllegalAccessException is thrown.
I understand that this exception is thrown when one tries to access a
method which should not be accessed (like private/protected/cross-package
access). However, both the EJB & these classes are in the same package.
So this should not be thrown.
Now the next thing I thought is that the EJB & the support classes are
being loaded by 2 different classloaders. I guess the classes under
/weblogic/myserver/serverclasses are being loaded by the WebLogic
Server ClassLoader & the EJB bean classes are being loaded by the
specialized EJB ClassLoader.
Now my question is,
1) Is it the case that the WebLogic Server does not recognize that the
EJB Bean class is in the same package as the support classes because
they are loaded by 2 separate class loaders? Please note that the EJB
jar file does not contain any support classes - so there is no
duplicate classes here.
2) Is this a bug?
3) What should I do to prevent this problem?
Some workarounds that I have done are:
1) Copied the Bean.class (implementation class of EJB bean) into the
serverclasses directory. Now the server does not throw any
IllegalAccessException. -- This, however, does not appeal as a solution
since it looks like the Bean class is now being loaded by the WebLogic
Class Loader instead of from the EJB jar file.
2) I changed all the default package access methods to public methods.
Works like a charm. -- Problem is that this is a third party set of classes
which I would like to avoid modifying.
Hope this is not too confusing. Please let me know if you need any further info.
Thanks much in advance,
--Das

You have to tell WLAS where to load your new classes. You can change
          workingDir of your JSP configuration in weblogic.properties to point to your
          new class directory.
          Cheers - Wei
          Hyung-Jin Kim <[email protected]> wrote in message
          news:[email protected]..
          > It seems that if I compile a class that a JSP uses while Weblogic is
          > running, Weblogic's class loader has this nasty habit of caching/writing
          > the class that already has loaded into memory into:
          >
          > weblogic/myServer/classfiles
          >
          > Weblogic then refers to the older class file under the above directory
          > when the server is started again. Is there any way to turn this "class
          > loader caching" off in Weblogic? Thanks!
          >
          > -hjk
          >

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 from JARs in web application

Hello,
I'm working on a web project in which we would like to dynamically load plugins without server restart.
We have developed our own ClassLoader in order to load the plugins from a path or with a user interface upload function.
The class loader hierarchy should be something like this:
      Bootstrap
          |
       System
          |
       Common
Catalina   Shared
        Webapp1 OurSystem
                   PluginClassLoaderThe all works fine within the classes loaded in the PluginClassLoader, but classes loaded in OurSystems class loader cannot access classes loaded in PluginClassLoader. For example when Hibernate tries to load classes definied in mapping files we got a java.lang.ClassNotFoundException.
Is there a way to load classes dynamically to OurSystems class loader or notify it about PluginClassLoaders classes?
Or is this a bad way to do it?
Best regards,
Kristoffer Renholm

Hi,
Sounds like a classpath problem that the folks in the workshop newsgroup
could help with. Try asking your question in:
http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=xover&group=weblogic.developer.interest.workshop&utag=
Bruce
Graeme Dougal wrote:
>
Hi, I am developing a web service with weblogic workshop. The JWS file references
other classes one of which is a factory for distributing various implementations
of an interface. I am trying to dynamically load the relevant class to be distributed
from the factory via its name, e.g. Class c = Class.forName(className)
However I keep getting a classNotFoundException.
Any ideas ??

Dynamic class loading from directory on server

Hello,
I am not sure if this is right forum, but I think it is more weblogic then ADF issue...
I am trying to create and load dynamically classes in weblogic (10.3.2.0). It is ADF application which I deploy to the weblogic server.
When I print ((GenericClassLoader)this.getClass().getClassLoader()).getFinderClassPath()I see the path to my directory (of course not just this path) C:\...\system11.1.1.2.36.55.36\DefaultDomain\servers\DefaultServer\tmp\_WL_user\test\753the\dynamicClasses(I have added directory dynamicClasses to manifest for deployment WAR profile).
In this directory I create class files. I have checked it, files are really created there.
When I try to load created class with the same classloader, for which I have printed classpath, ClassNotFoundException is thrown.
Please where could be the problem? Isn't it possible to load classes from directory instead of jar, do I need some special server configuration,...?
Thank you in advance
Qjeta

Hi Qjeta,
I am not sure but you can give it a try using URLClassLoader...Which we generally use for DynamicClassLoading:
import java.net.URLClassLoader;
<font color=maroon>
String path="C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses";
*URLClassLoader loader = new URLClassLoader(new URL[] { new URL(path) });*
Class c = loader.loadClass ("your.class.NameHere");
</font>
// Load class from class loader. filly qualified class name (means classname with package name) is the name of the class to be loaded
in the above code the "C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses" should be the location of the directory where your classes are placed....If you want to load a perticular Jar then you need to write the jarfile name as well like following:
C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses/Myapplication.jar
.================================
If the above code works for you then later you can even try to enhance your code by doing the following:
Thread.currentThread().setContextClassLoader(urlClassLoaderRef);
Thanks
Jay SenSharma
http://jaysensharma.wordpress.com (WebLogic Wonders Are Here)

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.

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!

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.

Order of class loading in a Web Application

Hi,
I have been trying to find out if there is a defined order in which classes contained in WEB-INF/classes
and/or WEB-INF/lib should be loaded.
There doesn't appear to be any mention of class loading order in either the J2EE 1.3 or J2EE 1.4
specifications. That does not mean that there isn't a defined class load order, it just means I haven't found one.
Typical behaviour from servers such as Tomcat (reference implementation of the Servlet Engine) show
that classes in WEB-INF/classes are loaded before classes contained in jars under WEB-INF/lib.
Because there doesn't appear to be a mandated class load order I cannot assume that the same
behaviour holds for all servers, unless someone here knows better of course.
The reason for the question is that relying on the exhibited class load order means we can patch web applications by simply putting the patch under the WEB-INF/classes directory.
If this should not be relied upon then patches will have to be applied directly to the affected jar files,
this is not a problem in itself however it is nice to be able to keep the patches out of the jars for
ease of rolling back patches without having to copy jar files all over the place.
Any insights would be welcome.
Thanks

If you say that it is server specific i don't find
that to be the correct answer b'cozI didn't give an answer, I am looking for one. I gave an example of the behaviour that Tomcat 4.1.x
exhibits, one that we currently make use of for patching web applications. My question was about
whether or not this behaviour can be relied upon.
the class files are depended on the jar files which
need to checked in first before getting loaded b'coz
it should check for dependent files before only while
getting deployed.This is why the class load order is important.
Is the Web Application Classloader going to look in WEB-INF/classes first every time followed
by WEB-INF/lib everytime, is the order undefined, or is it reversed?
More over if you just think of class loading mechanism
of classes folder only then it is loaded in the order
specified in the web.xml file.
in this we specify the order of loading.As far as I know web.xml does not allow you to specify where classes should be loaded from and in
which classpath order, you define which classes should be used for application components.
The only load order you can specify is the load order of servlets on startup.
If you know different I would love to know how you would configure web.xml to specify the classpath order
in which classes are loaded.

Weblogic Class Loader caching/writing classes to weblogic/myServer/classfiles

Similar Messages

Maybe you are looking for