Bug #19

cannot use bundle types as parameters for remote calls 2

Added by Jörg Plewe over 2 years ago. Updated over 2 years ago.

Status:Resolved Start:10/02/2009
Priority:Urgent Due date:
Assigned to:Jörg Plewe % Done:

90%
Category:Weaving
Target version:0.5.4

Description

see #18
see #6

When bundle types are used as parameters, their classes cannot be resolved on the remote side: ClassNotFoundException.

History

Updated by Jörg Plewe over 2 years ago

Reason: the stream sent to the remote site contains the parameters as in ObjectStream. The stream is received by a bundle serving http, which is not related to the sending bundle in any way. Thus, OSGi classloading prohibits that it can access the classes of the sending bundle.
It worked so far with primitive parameter types (java.lang.*) bc. the calling bundles object is resolved using OSGi's getService() which allows to get hold of the object without accessing its bundles classloader.

Way to solve: after resolving the service via getService() it's classloader is avialable simply by service.getClass().getClassLoader(). So the remote site has to load the information about the method to be called nut NOT the parameters in one step, resolve the service, get its classloader and then load the parameters in the context of that classloader (ObjectInputStreamWithClassloader can do).

Updated by Jörg Plewe over 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 90

Fixed with r2779 as suggested.

Factor more of the mechanics into Call, ServiceMethodCallServlet currently needs to know too much about the classloading details.

Updated by Philipp Haußleiter over 2 years ago

  • Target version set to 0.5.2

Updated by Philipp Haußleiter over 2 years ago

  • Target version changed from 0.5.2 to 0.5.4

Also available in: Atom PDF