Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / June 2007

Tip: Looking for answers? Try searching our database.

Dynamic loading of .class files and deserializing of object

Thread view: 
Goofball - 11 Jun 2007 18:45 GMT
We have such scenario:
There is a client and server nodes working together. Server node
transfers a .class (or .jar) file to the client with the serialized
version of object of the corresponding class. Client receives these
files and stores them in some folder. Now, we need to load that .class
(or .jar) file and deserialize object. Server also transfers full
qualifying class name as string for class loader to load class. The
problem rises when we try to deserialize the class. We tried to create
the instance of URLClassLoader with .class (or .jar) file and then we
tried to set that class loader as default for thread, but we received
error when doing deserialization. Then we tried to create our own
class loader (ExtendableClassLoader), set it as default and then do
the deserialization. Error was still there. :)
The sample code goes below:

/**
* Load file method is called by server using RMI
* @param file Bytes of .class or .jar file
* @param classTask Serialized object
* @param className Full-qualifying class name
* @param fileName File name of the .class or .jar file
*/
public void loadFile(byte[] file, byte[] classTask, String className,
String fileName)
              throws RemoteException {

        ...

         File jarFile = new File("./lib/" + fileName);
         try {
              // Saving .class or .jar file to fileName from bytes
              FileOutputStream fos = new FileOutputStream(jarFile);
              fos.write(file);
              fos.close();


ExtendableClassLoader.getInstance().addClassPath(jarFile.getAbsolutePath());

              Object object = null;
              try {
                   Class workClass1 =
ExtendableClassLoader.getInstance().findClass("java.io.ByteArrayInputStream");
                   Constructor constr = null;
                   Class[] parameterTypes = new Class[]
{ byte[].class };
                   constr =
workClass1.getConstructor(parameterTypes);
                   ByteArrayInputStream bais  =
(ByteArrayInputStream) constr.newInstance(classTask);
                   Class workClass2 =
ExtendableClassLoader.getInstance().findClass("java.io.ObjectInputStream");
                   Constructor constrOis = null;
                   Class[] parameterTypesOis = new Class[]
{ InputStream.class };
                   constrOis =
workClass2.getConstructor(parameterTypesOis);
                   ObjectInputStream ois = (ObjectInputStream)
constrOis.newInstance(bais);
                   object = ois.readObject();
              } catch (Exception e) {

                   // We've got here when the readObject method is
called

              }
         } catch (IOException e) {
              e.printStackTrace();
         }
    }
Tom Hawtin - 11 Jun 2007 19:27 GMT
> We have such scenario:
> There is a client and server nodes working together. Server node
[quoted text clipped - 9 lines]
> class loader (ExtendableClassLoader), set it as default and then do
> the deserialization. Error was still there. :)

Deserialisation and class loaders are ugly in the extreme. I think the
methods you need to override in ObjectInputStream are resolveClass and
resolveProxyClass.

From the API docs:

"The default implementation of this method in ObjectInputStream returns
the result of calling

"     Class.forName(desc.getName(), false, loader)

"where loader is determined as follows: if there is a method on the
current thread's stack whose declaring class was defined by a
user-defined class loader (and was not a generated to implement
reflective invocations), then loader is class loader corresponding to
the closest such method to the currently executing frame; otherwise,
loader is null. If this call results in a ClassNotFoundException and the
name of the passed ObjectStreamClass instance is the Java language
keyword for a primitive type or void, then the Class object representing
that primitive type or void will be returned (e.g., an ObjectStreamClass
with the name "int" will be resolved to Integer.TYPE). Otherwise, the
ClassNotFoundException will be thrown to the caller of this method."

The even uglier alternative to overriding reolve[Proxy]Class is to have
code loaded from the class loader you want to use call
ObjectInputStream. I did something similar for JDBC drivers. It's not
nice. http://jroller.com/page/tackline/20061101

Just for giggles, the system class loader is treated a little bit
differently. That's the [non-] "user-defined class loader" bit.

Tom Hawtin


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.