Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2387 major always 01-31-08 18:32 02-13-08 11:24
Reporter: pagedn Platform:  
Assigned To: ferg OS:  
Priority: normal OS Version:  
Status: closed Product Version: 3.0.20  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 3.1.5  
Summary: 0002387: burlap fails to convert resulting HashMap response objects to configured target class when invoked from spawned thread
Description: Hessian / Burlap Version: 3.0.20
Spring Version: 1.2.5

I'm using Spring with Burlap for remoting and it appears that a stage in the conversion process is being bypassed after return from the remote method invocation. Interestingly enough, the method invocation executes and returns as expected when the proxy is invoked directly from the parent thread handling the initial HTTP request. Unfortunately, the process that is being executed requires an extended period of time before reaching completion and because of this it is necessary to spawn a separate thread before forwarding the user to a page to monitor the overall progress of the task. Instead of returning a List containing the expected domain objects, I'm getting a List of HashMap instances initialized with the resulting property values. I've attached a TCP/IP monitor to view the response XML that is being returned from the separate thread invocation and it appears to be identical to the XML that is returned from the single threaded invocation. I attempted to step through the code but it appears that either spring or burlap is creating a dynamic proxy that prevents me from identifying the exact source of the problem. I'm not entirely convinced that the bug is in fact part of the burlap API, but it is my understanding the the involved spring remoting classes merely provide a simplified approach for integration and should not be tasked with any additional conversion responsibilities after the remote method invocation has returned a response. I can include a stack trace if necessary, but it basically consists of ClassCastException when attempting to cast a list element to the expected domain object class.
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:

Notes
(0002711)
pagedn   
02-03-08 13:32   
This issue has been resolved. I made the following modifications to the getDeserializer(String) method of the SerializerFactory class:

replaced lines:

ClassLoader loader = Thread.currentThread().getContextClassLoader();
Class cl = Class.forName(type, false, loader);

with:

Class cl = Class.forName(type);

I'm running OC4J 9.0.4 and the ApplicationContextClassLoader returned from getContextClassLoader is unable to resolve the target class when calling Class.forName(). It's quite possible that this issue is specific to OC4J (this is the only environment that I've tested in). Regardless, invoking Class.forName using the default class loader seems to have done the trick. You might also want to consider at least WARN level logging in the catch block following the attempt to resolve the class. It's generally not a good idea to "eat" exceptions without at least logging any potential problems that may have occurred during the execution of the code.

My thanks to anyone that may have spent time looking into this.
(0002714)
pagedn   
02-04-08 08:52   
Looks like the code changes aren't necessary. The problem was due to my lack of understanding about context classloaders on threads. I was able to assign the current classloader using the setContextClassloader method on Thread and the class is now resolved correctly when trying to obtain the proper deserializer.
(0002766)
ferg   
02-13-08 11:24   
server/334g

(adding logging. The deserialization behavior is correct.)