tudoutiao / h2database

Automatically exported from code.google.com/p/h2database
0 stars 0 forks source link

Deserializing an object that is outside the scope of the "default" ClassLoader causes ClassNotFoundException #180

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Start an application server (e.g. Tomcat) and create a connection H2 in
the Web application's context configuration (accessible using JNDI).
2. Store a serializable Java object that depends upon the current Web
application's class loader in a table using type OTHER.
3. Attempt to deserialize the object using getObject() from a ResultSet.

What is the expected output? What do you see instead?
The object should be deserialized. Instead, a ClassNotFoundException is thrown.

This is potentially related to
http://code.google.com/p/h2database/issues/detail?id=112. It seems like
really quirky behavior with regards to the way resolveClass() behaves in
ObjectInputStream. I have attached a patch that fixes the issue by using
the current thread context ClassLoader to deserialize the object -- this
fixed the issue for me.

Original issue reported on code.google.com by noahfontes@gmail.com on 23 Mar 2010 at 5:43

GoogleCodeExporter commented 8 years ago
Is this related the following bug?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4340158

I suggest apply your patch, but make it optional (disabled by default; can be 
enabled
using a system property). Is that OK for you?

I would like to have test cases for each feature. Could you create a simple
standalone test case please? It looks like you know how to do that :-)

Original comment by thomas.t...@gmail.com on 26 Mar 2010 at 4:22

GoogleCodeExporter commented 8 years ago
Hi,

I'm sorry, without test case I'm afraid I will not be able to apply your patch, 
and will close this issue.

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 28 Jun 2010 at 6:49

GoogleCodeExporter commented 8 years ago
If you have test case please submit it, I will then re-open this issue.

Original comment by thomas.t...@gmail.com on 2 Nov 2010 at 7:31

GoogleCodeExporter commented 8 years ago
Hi there,

I know this is a quite old bug by this point, but I finally got around to 
writing a test case for you. A patch is attached. It also supports the system 
property as you requested.

I think this is intentional behavior for the JVM, just a bit odd.

Thanks!

Original comment by nfon...@invectorate.com on 26 Oct 2011 at 8:26

GoogleCodeExporter commented 8 years ago
Actually, this patch has a more robust test. It makes sure the correct object 
is being deserialized.

Original comment by nfon...@invectorate.com on 26 Oct 2011 at 8:35

GoogleCodeExporter commented 8 years ago
Thanks a lot! I will have a look.

Original comment by thomas.t...@gmail.com on 28 Oct 2011 at 7:44

GoogleCodeExporter commented 8 years ago
Hi,

Thanks a lot! I have changed a few things (only cosmetic really) and committed 
the changes in the trunk.

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 3 Nov 2011 at 8:16

GoogleCodeExporter commented 8 years ago
Fixed in version 1.3.162

Original comment by thomas.t...@gmail.com on 26 Nov 2011 at 12:55