Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002387 [Resin] major always 01-01-08 18:32 02-13-08 11:24
Reporter pagedn View Status public  
Assigned To ferg
Priority normal Resolution fixed  
Status closed   Product Version 3.0.20
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.
Additional Information
Attached Files

- Relationships

- 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.)
 

- Issue History
Date Modified Username Field Change
01-01-08 18:32 pagedn New Issue
02-03-08 13:32 pagedn Note Added: 0002711
02-04-08 08:52 pagedn Note Added: 0002714
02-13-08 09:36 ferg Status new => acknowledged
02-13-08 11:24 ferg Note Added: 0002766
02-13-08 11:24 ferg Assigned To  => ferg
02-13-08 11:24 ferg Status acknowledged => closed
02-13-08 11:24 ferg Resolution open => fixed
02-13-08 11:24 ferg Fixed in Version  => 3.1.5

Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
33 total queries executed.
28 unique queries executed.
Powered by Mantis Bugtracker