The MarshalFactory has two marshallers/unmarshallers that are statically defined within a static block (Serializable and HTTP). Since these are core to remoting and part of the remoting package, is ok to have them statically defined. So if the remoting server is created with the locator url having dataType=serializable for example, is ok because when the remoting client asks the MarshalFactory for the marshaller for type 'serializable' it will return the SerializableMarshaller, since it is statically defined.
However, if the server adds a custom marshaller/unmarshaller to the MarshalFactory when it starts up and reflects this in its locator url (via dataType param), then the client is only aware of the dataType value and asks the MarshalFactory for the appropriate marshaller/unmarshaller. Problem is, the MarshalFactory in the client VM will not be aware of this new custom marshaller/unmarshaller (since was added on the server side). The real world example for this is the UnifiedInvoker. So when the UnifiedInvoker starts, it will add the InvocationMarshaller/InvocationUnMarshaller to the MarshalFactory with the data type of 'invocation'. The server invoker is started with it's locator url having dataType=invocation as part of it's parameter. For example: socket://localhost:8081/?datatype=invocation Then on the client side, when the UnifiedInvokerProxy is re-constituted in the client VM (from doing the JNDI lookup), it only knows about the locator url (i.e. socket://localhost:8081/?datatype=invocation). So when the remoting client is dynamically created on the client by the UnifiedInvokerProxy, it will try to look up the appropriate marshaller/unmarshallers for the client based on the data type (i.e. invocation). Since the MarshalFactory on the client does not have anything registered for type 'invocation', it will return null. I have hacked the UnifiedInvokerProxy to add the InvocationMarshaller/InvocationUnMarshaller to the MarshalFactory with associated type being 'invocatin' within a static block to make sure they are there. This is obviously very bad. I do like your idea of having the client go back to ask the server for the marshaller/unmarshaller if it does not exist on the client, since would make it very flexible (although a little slow for thei first invocation). However, think this shoudl be done using dynamic, remote classloading, was would want to pull them from the server. Guess could just get the fully qualified class name from the server and try to load it on the client, then actually pull the classes from the server if they do not exist locally, but would then have to worry about version conflicts between the client's jars and the server's jars. Obviously the ultimate goal would be to not even require a jboss-client.jar on the client side. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863996#3863996 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863996 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
