[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1131) Add configuration for Remoting servlet transport

[Howard Gao (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12444702#action_12444702 ] 

Howard Gao commented on JBMESSAGING-1131:
-----------------------------------------

That's will be great. Thanks Ron.  So JBM will update its JBoss remoting dependency to 1.1.1.SP12 and that will be fine. 

JBM has registered its own marshaller/unmarshaller with JB remoting, when writing to the stream, it replies on correct identification of the type of payload object. It presumes that in case of JBM payload, the only possible types are InvocationRequest and InvocationResponse. If the type is passed otherwise while the payload really belongs to JBM request/response, the result will be out of control.

When reading from the stream (unmarshalling), the JBM unmarshaller assumes it can always read a int from the inputstream passed in. This int is the ID JBM use to reconstruct its own packet. If Remoting somehow passes a different inputstream (maybe some internal packet that is not relevant to JBM) the JBM unmarshaller has no way to identify, that's why I got EOFException and so I catch it in my code.

 



> Add configuration for Remoting servlet transport
> ------------------------------------------------
>
>                 Key: JBMESSAGING-1131
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1131
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ron Sigal
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP05
>
>         Attachments: build.xml, code_changes.zip, messaging-servlet-service.xml, remoting-servlet-service.xml, ServletExample.java, web.xml
>
>
> In addition to the "http" transport, Remoting also has the http-based "servlet" transport.  The servlet transport is the same as the http transport on the client side (they both use org.jboss.remoting.transport.http.HTTPClientInvokr), but they are different on the server side.  In particular, CoyoteInvoker, the http transport server invoker, uses the network layer of tomcat/jbossweb, i.e., a ServerSocket with worker threads.  But in the servlet transport, a org.jboss.remoting.transport.servlet.web.ServerInvokerServlet fields invocations and passes them to org.jboss.remoting.transport.servlet.ServletServerInvoker.  The advantage, which came up in a forum thread recently (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4098850#4098850  and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=122218 ), is that only one ServerSocket is used.  In principle, it's the appropriate transport to use when the server is running inside JBossAS.  In fact, the wiki page "Accessing_EJB3s_over_HTTP_HTTPS" shows how to change the EJB3 transport from socket to servlet.  However, there have been a couple of problems.  For one, ServletServerInvoker has been a little behind CoyoteInvoker in its development, though I've been rectifying that (JBREM-675 "Problems with Servlet invoker").  For another, the servlet transport needs tomcat/jbossweb for unit testing, and we've never automated that, so it's not as well tested as CoyoteInvoker (JBREM-139 "need automated test for servlet server invoker").  However, I wanted to verify that JBossMessaging can run with the servlet transport, so I created a servlet example, parallel to the http example, along with the supporting configuration files, and it works. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira