[jboss-dev-forums] [Design of JBossCache] - Re: Common marshalling infrastructure
david.lloyd@jboss.com
do-not-reply at jboss.com
Wed Aug 6 23:43:03 EDT 2008
"scott.stark at jboss.org" wrote : So where does the invocation target class loader fit in, I don't see it in the apis.
It's factored out of the API currently - you'd have a customized ClassUnmarshaller that looks up the class in the appropriate classloader, similarly to how standard serialization works. The reason is that I can't really think of a good general solution (the needs of JBC & JBREM are very different in this area for example).
"scott.stark at jboss.org" wrote : I have been talking to Ron about some current remoting class loading issues that arise from the invocation handler being the only one who knows the correct class loader for unmarshalling application specific classes:
|
| 1. thread pool receives a remoting request.
| 2. unmarshall just enough to understand the request, but don't unmarshall any invocation payload. Application specific data needs to be isolated outside of the remoting control structures to allow this to happen.
| 3. dispatch the request to a handler.
| 4. handler sets the TCL
| 5. handler or its delegate unmarshalls application payload
| 6. application does what is does.
| 7. handler serializes application return/exception and then unsets the TCL
| 8. remoting layer completes request control information
|
This particular problem is specific to Remoting, so if you don't mind I'm going to move this bit back over to those forums before I reply...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169176#4169176
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169176
More information about the jboss-dev-forums
mailing list