There are a couple of issues here (I am actually working through a few of them currently due to a bug submitted recently). As it is now a Connector can have one and only one invoker, but can have multiple handlers.
The invoker has to have its marshaller/unmarshaller explicitly set for it (either via datatype=XXX in the locator url or by using its default one) when it starts. This is because the unmarshaller will be the one that is actually reading from the server invoker's transport's input stream (so no way to bind this dynamically based on client's preference as is no way to establish the initial handshake between client and server). This means that there is an associated constraint that all users of the Connector (and thus the associated server invoker) will have to use the same marshaller/unmarshaller. The reason that the EJBs using the unified invoker work without the datatype=invocation, as you have noted, is because I have explicitly hardcode the adding of the InvocationMarshaller/InvocationUnmarshaller in the UnifiedInvokerProxy and UnifiedInvoker. This was a hack, because at the time, I had no way to dynamically load marshallers. I have added this feature to remoting (explanation at http://www.jboss.org/wiki/Wiki.jsp?page=Remoting_Marshaller_Configuration), but have not made the fix to the UnifiedInvokerProxy and UnifiedInvoker. When I do make the fix (jira issue JBREM-62), I will need the datatype=invocation back in the locator (plus a few other parameters). So for now, probably best to define a new connector for the DTM. Another fix I can make pretty quickly is to update the InvocationMarshaller/InvocationUnMarshaller is to allow default marshalling behavior if is not of type org.jboss.Invocation (the EJB payload type). In essence, would mean any other users besides the ejb users, would see the exact same behavior as the SerializableMarshaller/SerializableUnMarshaller. I will be thinking about better long term solution for this problem (where can bind marshallers/unmarshaller dynamically). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3870445#3870445 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3870445 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
