| Anonymous | Login | Signup for a new account | 12-17-2024 08:23 PST |
| 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 | ||||
| 0002860 | [Hessian] | major | always | 08-21-08 23:40 | 12-16-09 16:45 | ||||
| Reporter | jghallen | View Status | public | ||||||
| Assigned To | ferg | ||||||||
| Priority | normal | Resolution | fixed | ||||||
| Status | closed | Product Version | 3.1.3 | ||||||
| Summary | 0002860: Hessian/Felix OSGi - classloader problem | ||||||||
| Description |
We use hessian within a OSGi bundle (Apache Felix 1.0.0) to communicate with a backend server. Felix is running embedded in a Tomcat (5.5.26). When creating the hessian proxy the current classloader must be supplied in the create() method in order for the service interface to be found. Default is to use the Thread.currentThread().getContextClassLoader() which will not find the service interface. The service interface and all supporting classes are packaged in a jar file in the OSGi bundle. The problem is that the deserialisation is allways performed using the Thread.currentThread().getContextClassLoader() classloader and not the classloader that was used to create the hessian proxy. This classloader can not find the classes in the to perform a correct deserialization of the return value, a simple transfer object. Instead of returning ArrayList<TO> it will return a ArrayList of HashMaps which is the default fallback. I can see the data as expected, but the mapping is not. I think this is a bug (please correct me if I'm wrong, and give me a pointer to where I can do some read-up). What are the proposed solutions and other options if we like to continue with the hessian RMI. Brgds/J |
||||||||
| Additional Information | |||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0003350) bramk 08-22-08 14:51 |
Hi J, without any knowledge of hessian or the specifics of your code, but with some experience with OSGi... Many legacy (in the OSGi context) libraries use the ContextClassLoader and this is a know issue. When a call to your service is made this classloader is not your BundleClassLoader and thus you may run into problems loading classes or recources. A common workaround is to temporarily switch the ContexClassLoader when your legacy code is invoked and switch it back when you are done. A simplified piece of code would look like.. ClassLoader bundleClassLoader = this.getClass().getClassLoader(); ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(bundleClassLoader); // invoke my legacy code Thread.currentThread().setContextClassLoader(originalClassLoader); Hope this helps you out! Let me know. Regards, Bram -- http://www.gxwebmanager.com [^] |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 08-21-08 23:40 | jghallen | New Issue | |
| 08-22-08 14:51 | bramk | Note Added: 0003350 | |
| 12-16-09 16:45 | ferg | Assigned To | => ferg |
| 12-16-09 16:45 | ferg | Status | new => closed |
| 12-16-09 16:45 | ferg | Resolution | open => fixed |
| 12-16-09 16:45 | ferg | Fixed in Version | => 4.0.3 |
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
30 total queries executed. 27 unique queries executed. |  |
