5:27 p.m.
I'm looking at an old Remoting issue, JBREM-167 "RMI Invoker does not use true
remoting marshalling/unmarshalling" and I have a question. This issue concerns the
Remoting RMI transport, which, as an alternative to the more commonly used
"socket" transport, makes invocations using Java RMI. If the
"jboss.remoting:service=Connector,transport=socket" Connector in
conf/jboss-service.xml were configured to use the RMI tranport, then EJB2 calls would be
transported by Java RMI.
Currently, the RMI transport uses
org.jboss.invocation.unified.marshall.InvocationMarshaller to marshal invocations on the
client side and org.jboss.invocation.unified.marshall.InvocationUnMarshaller to unmarshal
invocations on the server side. Their main function, other than serializing and
deserializing the invocation, is to add and remove transaction context information:
| // From InvocationMarshaller:
|
| public Object addDecoration(Object dataObject) throws IOException {
| if(dataObject instanceof InvocationRequest)
| {
| InvocationRequest remoteInv = (InvocationRequest) dataObject;
|
| if(remoteInv.getParameter() instanceof Invocation)
| {
| Invocation inv = (Invocation) remoteInv.getParameter();
|
| MarshalledInvocation marshInv = new MarshalledInvocation(inv);
|
| if(inv != null)
| {
| // now that have invocation object related to ejb invocations,
| // need to get the possible known payload objects and make sure
| // they get serialized.
|
| try
| {
|
marshInv.setTransactionPropagationContext(getTransactionPropagationContext());
| }
| catch(SystemException e)
| {
| log.error("Error setting transaction propagation
context.", e);
| throw new IOException("Error setting transaction context.
Message: " + e.getMessage());
| }
|
| // reset the invocation parameter within remote invocation
| remoteInv.setParameter(marshInv);
| }
| else
| {
| //Should never get here, but will check anyways
| log.error("Attempting to marshall Invocation but is null. Can
not proceed.");
| throw new IOException("Can not process data object due to the
InvocationRequest's parameter being null.");
| }
|
| }
| }
| return dataObject;
| }
|
and
| // From InvocationUnMarshaller:
|
| public Object removeDecoration(Object obj) throws IOException
| {
| if(obj instanceof InvocationRequest)
| {
| InvocationRequest remoteInv = (InvocationRequest) obj;
| Object param = remoteInv.getParameter();
|
| if(param instanceof MarshalledInvocation)
| {
| MarshalledInvocation mi = (MarshalledInvocation) param;
| Object txCxt = mi.getTransactionPropagationContext();
| if(txCxt != null)
| {
| TransactionPropagationContextImporter tpcImporter =
TransactionPropagationContextUtil.getTPCImporter();
|
mi.setTransaction(tpcImporter.importTransactionPropagationContext(txCxt));
| }
| }
| }
| return obj;
| }
|
On the other hand, when the server returns a response, no marshalling is performed on the
server side and no unmarshalling is performed on the client side: the response is passed
directly to the RMI runtime. The point of JBREM-167 is to change the RMI server invoker
to use a configured marshaller and to change the RMI client invoker to use a configured
unmarshaller. This way, someone could interpose, for example, encrypting or compressing
marshaller/unmarshallers, which is not currently possible.
My questions:
1. Does anyone care about having this feature?
2. This change would mean that the InvocationMarshaller would be used on the server side
when returning a response and InvocationUnMarshaller would be used on the client side to
unmarshal the response. Would adding and removing transaction context in the
server-to-client direction have any implications?
3. Since EJB3 handles transaction information in an interceptor and doesn't, by
default, configure any marshaller or unmarshaller, am I right that this issue is
irrelevant to EJB3?
Thanks,
Ron
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135118#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...