Class loading --- (a story that developers have to know when using a class loader)-next

How to construct a custom classloader

Since the custom classloader can solve the above problem, let's take a look at how we can use the custom classloader.

Combined with the original code in this article --- (in the differentversionspush directory), there is a filesystemclassloader. The class diagram is described as follows:

Figure 9.

 

Look at his method findclassbytes (string classname );

Public byte [] findclassbytes (string classname ){

Try {
String pathname = currentroot +
File. separatorchar + classname.
Replace ('.', file. separatorchar)
+ ". Class ";
Fileinputstream infile = new
Fileinputstream (pathname );
Byte [] classbytes = new
Byte [infile. Available ()];
Infile. Read (classbytes );
Return classbytes;
}
Catch (Java. Io. ioexception ioex ){
Return NULL;
}
}

Public class findclass (string name) throws
Classnotfoundexception {

Byte [] classbytes = findclassbytes (name );
If (classbytes = NULL ){
Throw new classnotfoundexception ();
}
Else {
Return defineclass (name, classbytes,
0, classbytes. Length );
}
}

Public class findclass (string name, byte []
Classbytes) throws classnotfoundexception {

If (classbytes = NULL ){
Throw new classnotfoundexception (
"(Classbytes = NULL )");
}
Else {
Return defineclass (name, classbytes,
0, classbytes. Length );
}
}

Public void execute (string codename,
Byte [] Code ){

Class Klass = NULL;
Try {
Klass = findclass (codename, Code );
Taskintf task = (taskintf)
Klass. newinstance ();
Task.exe cute ();
}
Catch (exception ){
Exception. printstacktrace ();
}
}

This filesystemclassloader class is used by the client to define the class, convert client. taskimpl (V1) to byte [], and then send byte [] to the RMI server for execution. (As mentioned above, defineclass () can execute any bytecode, from compiled files, networks, or even bcel bytecode engine libraries), on the server side, you can use filesystemclassloader to define the client as byte. taskimpl.

 

See the client code:

Public class client {

Public static void main (string [] ARGs ){

Try {
Byte [] code = getclassdefinition
("Client. taskimpl ");
Serverintf.exe cute ("client. taskimpl ",
Code );
}
Catch (RemoteException ){
RemoteException. printstacktrace ();
}
}

Private Static byte [] getclassdefinition
(String codename ){
String userdir = system. getproperties ().
Getproperty ("bytepath ");
Filesystemclassloader fscl1 = NULL;

Try {
Fscl1 = new filesystemclassloader
(Userdir );
}
Catch (filenotfoundexception
Filenotfoundexception ){
Filenotfoundexception. printstacktrace ();
}
Return fscl1.findclassbytes (codename );
}
}

In the serverimpl program of the RMI server, the byte [] from the client is received. Therefore, the filesystemclassloader constructs a class from byte [] and runs the class.

Note: every time a client request is received, filesystemclassloader will be re-instantiated (as can be seen in the execution results), which means that the client. impl is not found in classpath. Instead, it executes defineclass () through the findclass () of filesystemclassloader. In this way, every time filesystemclassloader creates a new instance ,, naturally, the classes defined by define are different. In this way, we can distinguish the two classes in RMI execution. (Client. taskimpl! = Client. taskimp has come to the conclusion in the previous article. )

Check the server-side Execution Code:

Public void execute (string codename, byte [] Code) throws RemoteException {

Filesystemclassloader = NULL;

Try {
Filesystemclassloader = new filesystemclassloader ();
Filesystemclassloader.exe cute (codename, Code );
}
Catch (exception ){
Throw new RemoteException (exception. getmessage ());
}
}

 

Server execution result:

Figure 10. Server display

The following two figures are displayed on the client.

Figure 11. Execution of Client1

Figure 12. Client2 execution result

 

Ha, the above is so many, it is finally step by step to teach everyone how to execute "different versions" of code in the same vmvm. (These codes have the same class name and package name ).

 

Class loaders is used in J2EE. It is not surprising that you have provided the following things...
The code in my web project a_war.war is com. mycom. Test, and the code in my wenb project in another B _war.war is com. mycom. Test, and they still work well.
When multiple ejbs are deployed on one server in a large EJB project, they will not affect each other in the War Project. The appserver also has its own load policy. For example, the jar package in your web application takes precedence over the one contained in the appserver. In addition, the classloader mechanism of J2EE is more detailed for you to refer to this article on TSS. Understanding J2EE application server class loading ubuntures "

Resource file:

Sample CodeFor this article

JDK 1.5 API docs

TheJava Language Specification

"Understanding extension class loading"In the Java tutorial

"Inside class loaders"FromOnjava

"Inside class loaders: Debugging"FromOnjava

"What version is your Java code?"FromJavaworld

"Understanding J2EE application server class loading ubuntures"FromTheserverside

Byte Code Engineering Library

Server-based Java programmingBy Ted neward

Original article:
Http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.htm