Taxonomy of class loader problems with Jakarta Commons Logging: "Class loading problems encountered when using JCL fall into three main categories:
Type-I: A java.lang.NoClassDefFoundError thrown when a class is inaccessible from a parent class loader even if the said class is available to a child class loader
Type-II: Assignment incompatibility of two classes loaded by distinct class loaders, even in case where the two classes are bit-wise identical.
Type-III: Holding references to a given class loader will prevent the resources loaded by that class loader from being garbage collected.
At least on a superficial level, Type-I problems are relatively easy to understand whereas Type-II problems are a bit harder to grasp at first glance. Consequently, we will start by illustrating problems of Type-I. Given their different nature, Type-III problems will be discussed only briefly towards the end of this document."
'via Blog this'
Wednesday, February 13, 2013
Understanding Classloaders: log4j in a J2EE Environment - O'Reilly Media
Understanding Classloaders: log4j in a J2EE Environment - O'Reilly Media: "Classloaders, as the name suggests, are responsible for loading classes within the JVM. Before your class can be executed or accessed, it must become available via a classloader. Given a class name, a classloader locates the class and loads it into the JVM. Classloaders are Java classes themselves. This brings the question: if classloaders are Java classes themselves, who or what loads them?
When you execute a Java program (i.e., by typing java at a command prompt), it executes and launches a native Java launcher. By native, I mean native to your current platform and environment. This native Java launcher contains a classloader called the bootstrap classloader. This bootstrap classloader is native to your environment and is not written in Java. The main function of the bootstrap classloader is to load the core Java classes."
'via Blog this'
When you execute a Java program (i.e., by typing java at a command prompt), it executes and launches a native Java launcher. By native, I mean native to your current platform and environment. This native Java launcher contains a classloader called the bootstrap classloader. This bootstrap classloader is native to your environment and is not written in Java. The main function of the bootstrap classloader is to load the core Java classes."
'via Blog this'
Tuesday, February 12, 2013
Java Application Architecture
Java Application Architecture: "Welcome to the homepage of Java Application Architecture: Modularity Patterns with Examples Using OSGi. The book is now available on Amazon in print and Kindle versions, iBooks, and other sites. You can also download an example to see what the book is all about."
'via Blog this'
'via Blog this'
Monday, February 11, 2013
How Classes are Found
How Classes are Found: "How the Java Launcher Finds Classes
The Java launcher, java, initiates the Java virtual machine. The virtual machine searches for and loads classes in this order:
Bootstrap classes - Classes that comprise the Java platform, including the classes in rt.jar and several other important jar files.
Extension classes - Classes that use the Java Extension mechanism. These are bundled as .jar files located in the extensions directory.
User classes - Classes defined by developers and third parties that do not take advantage of the extension mechanism. You identify the location of these classes using the"
'via Blog this'
The Java launcher, java, initiates the Java virtual machine. The virtual machine searches for and loads classes in this order:
Bootstrap classes - Classes that comprise the Java platform, including the classes in rt.jar and several other important jar files.
Extension classes - Classes that use the Java Extension mechanism. These are bundled as .jar files located in the extensions directory.
User classes - Classes defined by developers and third parties that do not take advantage of the extension mechanism. You identify the location of these classes using the"
'via Blog this'
Monday, February 4, 2013
java - How to configure classloader for ear in websphere 6.1 (specifically wsdl4j) - Stack Overflow
java - How to configure classloader for ear in websphere 6.1 (specifically wsdl4j) - Stack Overflow: "You have three simple steps to accomplish this
Place the jar file in the ear, we typically create a lib directory, but that is not necessary.
Update the manifest for the war to include this jar file.
Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server.
Edit: As an alternative, since you are only using the EAR to wrap the WAR and not actually sharing the jar file.
Put the jar in the lib directory of the WAR.
Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server. I do this via RAD by editing the application.xml file. It is IBM specific configuration, so if you are not using RAD you will have to figure out what files to change manually.
This should leave you with a consistent war between app servers."
'via Blog this'
Place the jar file in the ear, we typically create a lib directory, but that is not necessary.
Update the manifest for the war to include this jar file.
Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server.
Edit: As an alternative, since you are only using the EAR to wrap the WAR and not actually sharing the jar file.
Put the jar in the lib directory of the WAR.
Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server. I do this via RAD by editing the application.xml file. It is IBM specific configuration, so if you are not using RAD you will have to figure out what files to change manually.
This should leave you with a consistent war between app servers."
'via Blog this'
Subscribe to:
Posts (Atom)