Regarding database class loader
After write class.forName("drivername"); how does it work internally?
No such thing as a "database class loader"; it just uses the normal class loader.
1) class.forName("drivername") load the class, just like any other class.
2) a JDBC driver class that conforms to the JDBC specification will have an init block which registers the just loaded driver class with the DriverManager by calling its registerDriver() method.
Similar Messages
-
Performance issues with class loader on Windows server
We are observing some performance issues in our application. We are Using weblogic 11g with Java6 on a windows 2003 server
The thread dumps indicate many threads are waiting in queue for the native file methods:
"[ACTIVE] ExecuteThread: '106' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE
java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
java.io.File.exists(Unknown Source)
weblogic.utils.classloaders.ClasspathClassFinder.getFileSource(ClasspathClassFinder.java:398)
weblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:347)
weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:316)
weblogic.application.io.ManifestFinder.getSource(ManifestFinder.java:75)
weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
weblogic.application.utils.CompositeWebAppFinder.getSource(CompositeWebAppFinder.java:71)
weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
weblogic.utils.classloaders.CodeGenClassFinder.getSource(CodeGenClassFinder.java:33)
weblogic.utils.classloaders.GenericClassLoader.findResource(GenericClassLoader.java:210)
weblogic.utils.classloaders.GenericClassLoader.getResourceInternal(GenericClassLoader.java:160)
weblogic.utils.classloaders.GenericClassLoader.getResource(GenericClassLoader.java:182)
java.lang.ClassLoader.getResourceAsStream(Unknown Source)
javax.xml.parsers.SecuritySupport$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
javax.xml.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
javax.xml.parsers.FactoryFinder.findJarServiceProvider(Unknown Source)
javax.xml.parsers.FactoryFinder.find(Unknown Source)
javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
org.ajax4jsf.context.ResponseWriterContentHandler.<init>(ResponseWriterContentHandler.java:48)
org.ajax4jsf.context.ViewResources$HeadResponseWriter.<init>(ViewResources.java:259)
org.ajax4jsf.context.ViewResources.processHeadResources(ViewResources.java:445)
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:193)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
On googling this seems to be an issue with java file handling on windows servers and I couldn't find a solution yet. Any recommendation or pointer is appreciatedHi shubhu,
I just analyzed your partial Thread Dump data, the problem is that the ajax4jsf framework ResponseWriterContentHandler triggers internally a new instance of the DocumentBuilderFactory; every time; triggering heavy IO contention because of Class loader / JAR file search operations.
Too many of these IO operations under heavy load will create excessive contention and severe performance degradation; regardless of the OS you are running your JVM on.
Please review the link below and see if this is related to your problem.. This is a known issue in JBOSS JIRA when using RichFaces / ajaxJSF.
https://issues.jboss.org/browse/JBPAPP-6166
Regards,
P-H
http://javaeesupportpatterns.blogspot.com/ -
Dinamyc class loading and jar files
I'm new to java. I would like to load some plugins in my application (it's going to be packaged as a jar at the end). I managed to find some dinamyc class loading examples but they search for the classes to load in a directory.
This is the code:
public static void main(String[] args) {
File pluginDirectory = new File("src/pluginsreloaded/plugins");
if (!pluginDirectory.exists()) { // the plugin directory does not exist
System.out.println("The plugins directory does not exist!");
return;
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(".class");
String[] pluginFiles = pluginDirectory.list(filter);
for (int i = 0; i < pluginFiles.length; i++) {
if (pluginFiles.indexOf("$") == -1) {
System.out.println("Loading: " + pluginFiles[i].substring(0, pluginFiles[i].length() - 6));
IPlugin plugin = pm.loadPlugin(pluginFiles[i].substring(0, pluginFiles[i].length() - 6));
System.out.println(plugin.description());
protected static IPlugin loadPlugin(String name) {
// Query the plugin list for the plugin
PluginFactory _plugin = (PluginFactory) pluginList.get(name);
if (_plugin == null) { // the plugin is not loaded
try {
Class.forName("pluginsReloaded.plugins." + name);
// The plugin makes an entry in the plugin list
// when loaded
_plugin = (PluginFactory) pluginList.get(name);
if (_plugin == null) {
return null;
} catch (ClassNotFoundException e) {
System.out.println("Plugin " + name + " not found!");
return _plugin.create();
}IPlugin is an interface. I am using netbeans 5.0. The error I get is this:
Exception in thread "main" java.lang.NoClassDefFoundError: pluginsReloaded/plugins/plugin1 (wrong name: pluginsreloaded/plugins/plugin1)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at pluginsreloaded.PluginManager.loadPlugin(PluginManager.java:30)
at pluginsreloaded.Main.main(Main.java:44)
Java Result: 1As far as I can see it can't find the class. My question is how can I load the class/where can I find it?
Thanks.You can use the java.util.jar.JarFile class to enumerate the contents of a jar. It's not good practice to search for plugins in this way though. A plugin may well involve serveral classes, which don't all have to be internal. Furthermore its wise to avoid any comitment about the mechaism by which class files are to be fetched. You might want to do it remotely, some time, or load them from a database.
What seesms to be the standard approach is to put a list of plugin classes into the jar as a text file.
Plugins for a given purpose usually implement some specified interface, or extend some abstract class to which their objects can be cast once loaded (without this they aren't really much use).
Say your plugins implment org.myorg.WidgetFactory then you put a list of them, one fully qualified name to a line, in a file or jar entry called META-INF/services/org.myorg.WidgetFactory. You framework picks up all such files from the classpath using ClassLoader.getResources() and loads all the classes whose names if finds, hence you can add new sets of plugins just by adding a new jar or class directory to the class path. -
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 RenholmHi,
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 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! -
Dynamic Class Loading and Unloading
I am trying to create a system where the class name and method name is
picked up from a meta-data database and executed.
This was accompanied using Dynamic Class loading. I tried to extend this to
support versioning of meta-data. Here depending on the version of meta-data
different libraries can be loaded and different implementations of object
with the same name can be executed. This does not seem to work with Forte
3.0.
When the second Library is loaded the method execution does not work.
(Even though the unload flag on the LoadLibrary is set)
If the application is stopped and restarted pointing to the second library
there is no problem. In a running application a dynamically loaded library
does not seem to unload and reload a new library for the same class names.
Has anyone tried sometime similar, is there a workaround for this type of
problem.
- VivekI am trying to create a system where the class name and method name is
picked up from a meta-data database and executed.
This was accompanied using Dynamic Class loading. I tried to extend this to
support versioning of meta-data. Here depending on the version of meta-data
different libraries can be loaded and different implementations of object
with the same name can be executed. This does not seem to work with Forte
3.0.
When the second Library is loaded the method execution does not work.
(Even though the unload flag on the LoadLibrary is set)
If the application is stopped and restarted pointing to the second library
there is no problem. In a running application a dynamically loaded library
does not seem to unload and reload a new library for the same class names.
Has anyone tried sometime similar, is there a workaround for this type of
problem.
- Vivek -
Dynamic class loading when CODEBASE is unreachable. A bug?
Let us suppose that we have a large-scale distributed application with ca. 1000 participants communicating via RMI and utilizing dynamic class loading. As we all know, a HTTP code server must be available for this purpose in order to provide dynamically downloaded code, usually the communication proxy code of remote objects. In a real-world scenario, the HTTP server will never be 100% available, so that we will have cases that a Java process will not be able to download the necessary Java classes, causing the RMI communication to fail with a ClassNotFoundException or similar exception. In such a case, a robust application would perform some recovery activities and retry the remote call. Eventually, the HTTP server becomes available again and the distributed system recovers automatically. This seems to work fine with J2SE 1.4.2_10, but not with 1.4.2_11 and newer versions. Considering Java 5, the Update 9 exhibits the same problem.
For tracking down the problem, I've written a simple distributed test application, consisting of a client and a server. A server listens on a port, and sends a MarshalledObject to the client. The code of the MarshalledObject is annotated with the value of the "java.rmi.server.codebase" system property. The annotation contains an URL of the JAR file containing the code of the original object. The client connects to the server, reads data form the socket and unmarshalls the original object. This is basically the same procedure as when objects are accross the wire as arguments/return values/exceptions by the RMI/JRMP engine. This procedure is repeated forever in the loop. Due to the fact that the client's CLASSPATH doesn't contain the code of the original object, this code should dynamically be loaded from the HTTP server using the appropriate annotation provided by the server.
If we start the client while the HTTP server is down, the client will keep generating the ClassNotFoundException over and over again, as expected. So far, so good. If we now start the HTTP server while the client is still running, we will observe different behaviors, depending on the version of the client's JVM:
1. In J2SE 1.4.2_10, the client will download the code from the HTTP server and successfully unmarshal the original object sent by the server. ClassNotFoundExceptions will not be generated again.
2. In J2SE 1.4.2_11, 1.4.2_12 and 1.4.2_13 as well as in J2SE 5.0 Update 9, the client will continue generating ClassNotFoundExceptions. Analysis of the HTTP server's access log shows that there were no attempts to download the JAR file required for unmarshaling the object sent by the server.
It seems that in the newer JVM versions the RMI engine remembers URLs which have failed and does not attempt to access them anymore. Althogh this may have some advantages considering the overall network load, the dynamical class loading becomes practically useless in productive large distributed systems. The very first attempt to load the codebase of the communication peer must succeed, otherwise the whole process must be restarted for the communication to work, which is a very expensive (and for most customers unacceptable) operation in terms of preformance and resources usage.
Should this be seen as a bug or a feature of the JVM? What do you think?
Regards,
Miran
Here is the code to reproduce:
Server code
package server;
import java.net.*;
import java.rmi.*;
import java.io.*;
public class Server implements Serializable {
private int value = 42;
public Server() {
public String toString() {
return "The Answer is " + value;
public static void main( String[] args ) {
if( args.length!=1 ) {
System.out.println( "Usage: server.Server <port>" );
System.exit( 1 );
try {
MarshalledObject data = new MarshalledObject( new Server() );
int port = Integer.parseInt( args[0] );
ServerSocket serverSocket = new ServerSocket( port );
System.out.println( "Accepting connections..." );
while( true ) {
Socket s = serverSocket.accept();
new Thread( new SocketHandler( s, data ) ).start();
} catch( Exception ex ) {
ex.printStackTrace();
System.exit( 0 );
public static class SocketHandler implements Runnable {
private Socket s;
private Serializable data;
public SocketHandler( Socket s, Serializable data ) {
this.s = s;
this.data = data;
public void run() {
try {
OutputStream os = s.getOutputStream();
ObjectOutputStream oos = new ObjectOutputStream( os );
oos.writeObject( data );
oos.close();
os.close();
s.close();
System.out.println( "Serving socket succeeded" );
} catch( Exception ex ) {
System.out.println( "Serving socket failed" );
ex.printStackTrace();
Client code
package client;
import java.rmi.*;
import java.net.*;
import java.io.*;
public class Client {
public static void main( String[] args ) {
if( args.length!=1 ) {
System.out.println( "Usage: client.Client <port>" );
System.exit( 1 );
try {
if( System.getSecurityManager()==null ) {
System.setSecurityManager( new RMISecurityManager() );
int port = Integer.parseInt( args[0] );
for( int i = 1; true; ++i ) {
try {
Socket s = new Socket( "localhost", port );
InputStream is = s.getInputStream();
ObjectInputStream ois = new ObjectInputStream( is );
Object o = ois.readObject();
ois.close();
is.close();
s.close();
Object umo = ((MarshalledObject) o).get();
System.out.println( i + ". Retreiving MarshalledObject succeeded: "
+ umo );
} catch( Exception ex ) {
System.out.println( i + ". Retreiving MarshalledObject failed" );
ex.printStackTrace();
System.out.println( i + ". Waiting for 10 sec" );
Thread.sleep( 10000 );
} catch( Exception ex ) {
ex.printStackTrace();
System.exit( 0 );
Start command for the server
java -cp server.jar -Djava.rmi.server.codebase="http://localhost/playground/server.jar" server.Server 33933
Start command for the client
java -cp client.jar -Djava.security.policy=all.policy client.Client 33933
The policy.all file should look as follows
// All permissions
grant {
permission java.security.AllPermission;
};The server.jar file should only contain the classes from the server package. This file should also be made accessible via HTTP (e.g. by using the Apache HTTP server).
The client.jar file should only contain the classes from the client package.no body know about this??
-
MBean calling ejb class loading issue
Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because the
mbean class loader would load the interface, preventing ejb reload( Thats what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader) to
load the mbeans, but now I have the problem that when the mbean looks up the
home in jndi the cast fails ie the jndi object has an interface class loaded by
the ejb class loader but the mlet has its own loaded home interface. These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that loaded
the interface class (jndi object) and then have the mbean use that class loader
to load its copy of the interface class. Seems a bit complex. Im sure I missed
something obvious.
Thanks
Pete MarshallPete,
could you explain better your thoughts...
I'm interested to hear them.
regards,
Pedro Salazar.
Pete Marshall wrote:
Must think before typing..
If I have the ejb register a listener on the mbean and have the mbean emit an
event the detyped notification from the mbean will break the link between the
mbean class loader and the ejb loader. I think ;-) Ill try it.
Pete
"Pete Marshall" <[email protected]> wrote:
Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because
the
mbean class loader would load the interface, preventing ejb reload( Thats
what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader)
to
load the mbeans, but now I have the problem that when the mbean looks
up the
home in jndi the cast fails ie the jndi object has an interface class
loaded by
the ejb class loader but the mlet has its own loaded home interface.
These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that
loaded
the interface class (jndi object) and then have the mbean use that class
loader
to load its copy of the interface class. Seems a bit complex. Im sure
I missed
something obvious.
Thanks
Pete Marshall -
WebLogic class loading conflict causing ClassCastException
Hi everyone,
I am using Oracle XML Parser v2 for my JCA adapter and I am getting the following exception when method from my adapter is invoked.
java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to oracle.xml.jaxp.JXDocumentBuilderFactory
I have already placed Oracle XML Parser v2 library (xmlparserv2.jar) inside $DOMAIN_DIR/lib. Below is the line that throws above exception.
JXDocumentBuilderFactory factory =(JXDocumentBuilderFactory)JXDocumentBuilderFactory.newInstance();
So it seems like WebLogic is using different JXDocumentBuilderFactory and there seems to be problem with class loading. How can I resolve this issue? Thanks in advance.
Regards,
K.H
Edited by: K Hein on Dec 16, 2010 12:38 AMHI,
You can use Class Loader Filtering feature of WebLogic to isolate the Classloaders....as described in the following link: http://middlewaremagic.com/weblogic/?page_id=192
Thanks
Jay SenSharma
http://middlewaremagic.com/weblogic (Middleware Magic Is Here) -
Cocoon2 weblogic (5.1 sp6) class loader security problem
Hello folks,
System:
Cocoon: v2.0
JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
OS: NT4 SP5
Servlet: v2.2
AppServer: Weblogic 5.1 SP6
Symptoms:
I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
figured out what libraries I need on the Weblogic's classpath, I managed
to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
servlet and wrap the HttpServletRequest in MyRequest to provide the XML
content. I changed the line <map:generators default="request"> in
sitemap.xmap to specify the location of the source. Configuration files
seem to be read correctly and the file
<myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
is generated (but there is no class file generated)!
I looked at the cocoon.log file and looks like a class loader security
problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
problem? Any help is much appreciated!
cocoon.log file generated:
DEBUG 62 [cocoon ] (ExecuteThread-11): Using configuration file:
/cocoon.xconf
INFO 62 [cocoon ] (ExecuteThread-11): Reloading from:
file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
DEBUG 93 [cocoon ] (ExecuteThread-11): New Cocoon object.
DEBUG 93 [cocoon ] (ExecuteThread-11): Using parser:
org.apache.cocoon.components.parser.JaxpParser
DEBUG 109 [cocoon ] (ExecuteThread-11): Creating Repository with
this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 109 [cocoon ] (ExecuteThread-11): Classpath =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
DEBUG 109 [cocoon ] (ExecuteThread-11): Work directory =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 125 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 390 [cocoon ] (ExecuteThread-11): Root configuration:
cocoon
DEBUG 390 [cocoon ] (ExecuteThread-11): Configuration version:
2.0
DEBUG 390 [cocoon ] (ExecuteThread-11): Setting up components...
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.parser.Parser =
org.apache.cocoon.components.parser.JaxpParser)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.generator.ProgramGenerator =
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.url.URLFactory =
org.apache.cocoon.components.url.URLFactoryImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.saxconnector.SAXConnector =
org.apache.cocoon.components.saxconnector.NullSAXConnector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.datasource.DataSourceComponentSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.pool.PoolController =
org.apache.cocoon.components.ComponentPoolController)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
= org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.store.Store =
org.apache.cocoon.components.store.MemoryStore)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.classloader.ClassLoaderManager =
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
DEBUG 422 [cocoon ] (ExecuteThread-11): Setting up the sitemap.
DEBUG 422 [cocoon ] (ExecuteThread-11): Sitemap location =
sitemap.xmap
DEBUG 703 [cocoon ] (ExecuteThread-11): ComponentFactory creating
new instance of org.apache.cocoon.components.url.URLFactoryImpl.
DEBUG 703 [cocoon ] (ExecuteThread-11): Getting the URLFactories
DEBUG 703 [cocoon ] (ExecuteThread-11): for protocol:
resource org.apache.cocoon.components.url.ResourceURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): for protocol: context
org.apache.cocoon.components.url.ContextURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): Beginning sitemap
regeneration
DEBUG 718 [cocoon ] (ExecuteThread-11): Making URL from
file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
DEBUG 718 [cocoon ] (Thread-1): Could not find ComponentHandler,
attempting to create one for role:
org.apache.cocoon.components.language.generator.ServerPagesSelector
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.GeneratorSelector.
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element:
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: markup-languages
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
xsp
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
for sitemap
DEBUG 734 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 734 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: programming-languages
DEBUG 750 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.programming.java.JavaLanguage.
DEBUG 750 [cocoon ] (Thread-1): Looking up
org.apache.cocoon.components.classloader.ClassLoaderManager
DEBUG 750 [cocoon ] (Thread-1): Setting the parameters
DEBUG 750 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.programming.java.JavaLanguage for
java
DEBUG 765 [cocoon ] (Thread-1): The instance was not accessible,
creating it now.
DEBUG 765 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 1718 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 1718 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 4109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4109 [cocoon ] (Thread-1): Can't load ServerPage
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4359 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 4359 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 6109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
ERROR 6109 [cocoon ] (Thread-1): Error compiling sitemap
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (ExecuteThread-11): Changing Cocoon
context(sitemap.xmap) to prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): from
context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): at URI
DEBUG 6109 [cocoon ] (ExecuteThread-11): New context is
file:/D:/Programs/cocoon-1.8.2/samples/
ERROR 6140 [cocoon ] (ExecuteThread-11): Problem with servlet
org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
not available.
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
INFO 6187 [cocoon ] (ExecuteThread-11): '' Processed by Apache
Cocoon 2.0a4 in 5.75 seconds.
================================================================
Regards,
GeorgiHello folks,
System:
Cocoon: v2.0
JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
OS: NT4 SP5
Servlet: v2.2
AppServer: Weblogic 5.1 SP6
Symptoms:
I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
figured out what libraries I need on the Weblogic's classpath, I managed
to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
servlet and wrap the HttpServletRequest in MyRequest to provide the XML
content. I changed the line <map:generators default="request"> in
sitemap.xmap to specify the location of the source. Configuration files
seem to be read correctly and the file
<myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
is generated (but there is no class file generated)!
I looked at the cocoon.log file and looks like a class loader security
problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
problem? Any help is much appreciated!
cocoon.log file generated:
DEBUG 62 [cocoon ] (ExecuteThread-11): Using configuration file:
/cocoon.xconf
INFO 62 [cocoon ] (ExecuteThread-11): Reloading from:
file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
DEBUG 93 [cocoon ] (ExecuteThread-11): New Cocoon object.
DEBUG 93 [cocoon ] (ExecuteThread-11): Using parser:
org.apache.cocoon.components.parser.JaxpParser
DEBUG 109 [cocoon ] (ExecuteThread-11): Creating Repository with
this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 109 [cocoon ] (ExecuteThread-11): Classpath =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
DEBUG 109 [cocoon ] (ExecuteThread-11): Work directory =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 125 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 390 [cocoon ] (ExecuteThread-11): Root configuration:
cocoon
DEBUG 390 [cocoon ] (ExecuteThread-11): Configuration version:
2.0
DEBUG 390 [cocoon ] (ExecuteThread-11): Setting up components...
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.parser.Parser =
org.apache.cocoon.components.parser.JaxpParser)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.generator.ProgramGenerator =
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.url.URLFactory =
org.apache.cocoon.components.url.URLFactoryImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.saxconnector.SAXConnector =
org.apache.cocoon.components.saxconnector.NullSAXConnector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.datasource.DataSourceComponentSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.pool.PoolController =
org.apache.cocoon.components.ComponentPoolController)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
= org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.store.Store =
org.apache.cocoon.components.store.MemoryStore)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.classloader.ClassLoaderManager =
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
DEBUG 422 [cocoon ] (ExecuteThread-11): Setting up the sitemap.
DEBUG 422 [cocoon ] (ExecuteThread-11): Sitemap location =
sitemap.xmap
DEBUG 703 [cocoon ] (ExecuteThread-11): ComponentFactory creating
new instance of org.apache.cocoon.components.url.URLFactoryImpl.
DEBUG 703 [cocoon ] (ExecuteThread-11): Getting the URLFactories
DEBUG 703 [cocoon ] (ExecuteThread-11): for protocol:
resource org.apache.cocoon.components.url.ResourceURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): for protocol: context
org.apache.cocoon.components.url.ContextURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): Beginning sitemap
regeneration
DEBUG 718 [cocoon ] (ExecuteThread-11): Making URL from
file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
DEBUG 718 [cocoon ] (Thread-1): Could not find ComponentHandler,
attempting to create one for role:
org.apache.cocoon.components.language.generator.ServerPagesSelector
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.GeneratorSelector.
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element:
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: markup-languages
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
xsp
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
for sitemap
DEBUG 734 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 734 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: programming-languages
DEBUG 750 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.programming.java.JavaLanguage.
DEBUG 750 [cocoon ] (Thread-1): Looking up
org.apache.cocoon.components.classloader.ClassLoaderManager
DEBUG 750 [cocoon ] (Thread-1): Setting the parameters
DEBUG 750 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.programming.java.JavaLanguage for
java
DEBUG 765 [cocoon ] (Thread-1): The instance was not accessible,
creating it now.
DEBUG 765 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 1718 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 1718 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 4109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4109 [cocoon ] (Thread-1): Can't load ServerPage
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4359 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 4359 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 6109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
ERROR 6109 [cocoon ] (Thread-1): Error compiling sitemap
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (ExecuteThread-11): Changing Cocoon
context(sitemap.xmap) to prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): from
context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): at URI
DEBUG 6109 [cocoon ] (ExecuteThread-11): New context is
file:/D:/Programs/cocoon-1.8.2/samples/
ERROR 6140 [cocoon ] (ExecuteThread-11): Problem with servlet
org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
not available.
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
INFO 6187 [cocoon ] (ExecuteThread-11): '' Processed by Apache
Cocoon 2.0a4 in 5.75 seconds.
================================================================
Regards,
Georgi -
Implementing a secure class loader..
Hello,
We have a custom class loader which loads in custom packages from the database or from the file system. We want to ensure that these custom classes do not read or write into the file system. I want to restrict access to these classes when creating them. I read that by setting the proper permissions when defining the class, this could be possible. Here is my implementation of the class loader :
import java.io.File;
import java.io.FileInputStream;
import java.io.FilePermission;
import java.io.IOException;
import java.net.SocketPermission;
import java.net.URL;
import java.security.AccessController;
import java.security.CodeSource;
import java.security.PermissionCollection;
import java.security.Permissions;
import java.security.PrivilegedExceptionAction;
import java.security.SecureClassLoader;
public class TestClassLoader extends SecureClassLoader {
JarParser jp;
public TestClassLoader(JarParser jp) {
super();
this.jp = jp;
public Class findClass(final String name) throws ClassNotFoundException {
try {
return(Class)
AccessController.doPrivileged (
new PrivilegedExceptionAction() {
public Object run() throws ClassNotFoundException {
byte[] buf = null;
try {
if(jp == null)
throw new ClassNotFoundException("Jar file not found");
String className = name.replace( '.', '/' ) + ".class";
buf = jp.getResource(className);
if(buf == null || buf.length == 0)
throw new ClassNotFoundException("Class not found");
CodeSource cs = getCodeSource(name);
return defineClass(name, buf, 0, buf.length, cs);
catch(Exception e) {
throw new ClassNotFoundException(name, e);
catch(Exception e) {
throw new ClassNotFoundException(name, e);
* @param name
protected CodeSource getCodeSource(String name) {
try {
return new CodeSource(new URL("file", "localhost", name), null);
catch(Exception e){
e.printStackTrace();
return null;
protected PermissionCollection getPermissions(CodeSource cs) {
PermissionCollection pc = new Permissions();
pc.add(new RuntimePermission("exitVM"));
pc.add(new FilePermission("${user.home}${/}*", "read"));
pc.add(new FilePermission("${user.dir}${/}*", "read"));
pc.add(new SocketPermission("localhost", "resolve"));
return pc;
public static void main(String[] args) {
try {
byte[] bytes = new byte[8192];
long ttlBytesRead = 0;
int noOfBytesToRead = 0;
File readFile = new File("test.jar");
// "length" here indicates the total no of bytes to read.
// This is equal to the file size sans the offset value.
long length = readFile.length();
Long temp;
FileInputStream readFis = null;
// Create the RandomAccessFile
try{
readFis = new FileInputStream(readFile);
catch(Exception e) {
throw new IOException(e.getMessage());
long tempLong;
StringBuffer buffer = new StringBuffer();
do {
if ((length - ttlBytesRead) > 8192)
tempLong = 8192;
else
tempLong = (length - ttlBytesRead);
temp = new Long((length - ttlBytesRead) > 8192 ? 8192 : (length - ttlBytesRead));
noOfBytesToRead = temp.intValue();
if(noOfBytesToRead == 0)
break;
// Read the specified no of bytes into the byte
// array from the file.
try {
readFis.read(bytes,0,noOfBytesToRead);
catch(Exception e1) {
throw new IOException(e1.getMessage());
String str = new String(bytes, 0, noOfBytesToRead);
buffer.append(str);
ttlBytesRead += noOfBytesToRead;
} while(ttlBytesRead < length);
try {
readFis.close();
catch(Exception e1) {}
JarParser jp = new JarParser("test.jar", buffer.toString().getBytes());
TestClassLoader tcl = new TestClassLoader(jp);
Class class1 = tcl.findClass("com.test.TestFileWrite");
Object obj = class1.newInstance();
catch(Exception e) {
e.printStackTrace();
}JarParser is the class which parses through the jar file and caches the contents as bytes.
The test.jar contains a single class which writes into the user's home directory. As you can see, I have granted only read access on the home dir.
When I run this however, the newly loaded class does manage to write into the file system with no problems. Is there anything further that I need to do to enable restriction on the file system ?
Thanks.If I've been reading correctly, they don't want you
subclassing SecurityManager for security any more.
Everything should be handled by the AccessController
using Permission objects. The easiest way to configure
the AccessController is through policy files.erg. where did you read this? I checked the 1.5.0 beta API just now, and nothing is officially deprecated.
:{ I don't have time to figure out the AccessController API right now.
I have yet to find a good tutorial on the matter of
security and classloaders. If anyone has a good
reference, it would be much appreciated.I second that.
And as a temporary solution (because we're already behind schedule), I went ahead and wrote my own SecurityManager, using the ideas I mentioned above.
I'm posting it at the site below in case anyone can offer any feedback (such as pointing out fatal weaknesses). We tried yesterday for an hour or so to break it, and it withstood all our tests; but security is not our specialty, so there's probably room for improvement.
(I'd post it in this message, but it's a wee bit large.)
www.personal.utulsa.edu/~jeremy-wood/software/ThreadBasedSecurityManager.java
(And if it passes your scrutiny and looks useful, feel free to use it. But note the disclaimers.) -
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�reI'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? -
Class Loader Time in VisualGC 3.0-Display
Hello,
I�m monitoring my application with visualgc 3.0 under jdk1.5_09.
I�m wondering why the Class Loader Time-Panel always shows activity even the amount of loaded classes remains nearly constant.
What is shown is this panel??? Does the classloader check if a certain class is allready loaded and is this activity also shown in the panel? Or does it show only activity if a new class is really loaded?
Please help me understanding this tool.
Thank you very much!!
Greeting
Gregorhello dear
Where is the jboss.jar mentioned?The error is due to unavialibility of the class.
So please
1.set jboss.jar,it is avialable at %Jboss_HOME%/server/defult/lib/jboss.jar.
2. make sure that ur bean jar file on the client class path
hope it will slove ur problem
regards
sachin -
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 PMGuys, 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
Maybe you are looking for
-
how to transfer data from an execel file to an internal file for a BDC program?
-
Camera Raw 6.7/LR4.1 photos corrupted
I have Photoshop 5, LR4.1, Windows 7 64-bit, Camera Raw 6.7 and a Canon 5D Mk3. When I import photos from the camera into LR4.1 some get corrupted with posterised type artifacting. While I quite like this from a creative aspect, it's not what is on t
-
How do you check CPU temperature w/o using Bios?
I saw many many posts about this and just want to make sure I get the correct software to do this (If I can) I'd like to be able to check my temperature without going to the BIOS. Motherboard K9N2 SLI Platinum Windows Vista 64 bit AMD Phenom 9950
-
hi there, has anyone had any experience with applescript and custom tags? i've gotten so far as to display the name of custom tags i've added, but i want to find a way to batch erase some i've added on several thousand pictures. any hints? j here's a
-
How to install two or more exe files in a single set up ?
hi I want to make a setup (deployment project ) using visual studio 2010. my requirement is to install a third party software before installing my windows form setup application. how can I manage the setup creation process ?