[jboss-user] [Remoting] - Re: JBoss remoting integration with legacy systems

[ron.sigal@jboss.com]

Hi Eliezer,

Trustin has given the answer I always give (thanks, Trustin!), but since this issue has come up recently in a question from our support staff, and since I have put some time into demonstrating that a client using ordinary sockets can talk to a Remoting server using the socket transport, I'm going to elaborate a little bit.

As Trustin mentioned, the socket transport uses either ObjectOutputStream/ObjectInputStream or JBossObjectOutputStream/JBossObjectInputStream by default, so normally you would have to do the same on the client.  Also, the socket transport, since version 2.0.0.GA, has added an extra version byte before each transmission, so you would also have to do that.

The solution I proposed to the support guys worked around both of these requirements.

1. The choice of streams is made by the implementations of the org.jboss.remoting.marshal.Marshaller and org.jboss.remoting.marshal.UnMarshaller interfaces, and the default choices for the socket transport (org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller) use object streams.  To avoid using object streams, then, you can write and configure your own marshaller and unmarshaller.  In my example, I used


  | public class IntegrationMarshaller implements Marshaller
  | {
  |    private static final long serialVersionUID = 1L;
  | 
  |    public Marshaller cloneMarshaller() throws CloneNotSupportedException
  |    {
  |       return new IntegrationMarshaller();
  |    }
  | 
  |    public void write(Object dataObject, OutputStream output) throws IOException
  |    {
  |       PrintStream ps = new PrintStream(output);
  |       if (dataObject instanceof String)
  |       {
  |          ps.println((String) dataObject);
  |          ps.flush();
  |       }
  |       else if (dataObject instanceof InvocationRequest && ((InvocationRequest) dataObject).getParameter() instanceof String)
  |       {
  |          ps.println(((InvocationRequest) dataObject).getParameter());
  |          ps.flush();
  |       }
  |       else
  |       {
  |          throw new IOException("unexpected data type: " + dataObject);
  |       }
  |    }
  | }
  | 

and


  | public class IntegrationUnmarshaller implements UnMarshaller
  | {
  |    private static final long serialVersionUID = 1L;
  | 
  |    public UnMarshaller cloneUnMarshaller() throws CloneNotSupportedException
  |    {
  |       return new IntegrationUnmarshaller();
  |    }
  | 
  |    public Object read(InputStream inputStream, Map metadata) throws IOException, ClassNotFoundException
  |    {
  |       BufferedReader br = new BufferedReader(new InputStreamReader(inputStream));
  |       String s = br.readLine();
  |       if (s == null)
  |       {
  |          throw new EOFException();
  |       }
  |       System.out.println(this + " received: " + s);
  |       return s;
  |    }
  | 
  |    public void setClassLoader(ClassLoader classloader)
  |    {
  |    }
  | }
  | 

Of course, they handle only strings, but that was OK for the example.  You might need to do something different.

Now, to tell Remoting to use these classes, you can use the "marshaller" and "unmarshaller" parameters.  For example:


  | socket://127.0.0.1:8888/?marshaller=your.package.IntegrationMarshaller&unmarshaller=your.package.IntegrationUnmarshaller
  | 

2. You can tell Remoting to eliminate the version byte by telling it to be compatible with the versions that preceded 2.0.0.  The way to do this is to set the system property "jboss.remoting.pre_2_0_compatible" to "true".  In Remoting 2.4/2.5, you can also set "jboss.remoting.pre_2_0_compatible" to "true" in the InvokerLocator.

Let us know how is goes.

-Ron

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216415#4216415

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216415