]
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#... 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: