[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1131) Add configuration for Remoting servlet transport
David Smiley (JIRA)
jira-events at lists.jboss.org
Tue Feb 26 08:50:42 EST 2008
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1131?page=comments#action_12400587 ]
David Smiley commented on JBMESSAGING-1131:
-------------------------------------------
I'm trying to employ this but I've not been successful. I put the servlet-invoker.war from JBoss remoting 2.2.0 into my JBoss AS 4.2.1 w/ JBoss Messaging 1.4.0.SP3 installed already (w/ the jboss remoting 2.2.2.SP4-brew per the instructions). I dropped the *-service.xml attachments here into my deploy directory. I went to the existing http config example in my JBoss messaging distro, modified the JNDI ConnectionFactory path to be /ServletConnectionFactory (I also modified its build.xml to not deploy or undeploy files; I prefer to do that manually). I modified remoting-servlet-service.xml to have the path: servlet-invoker/ServerInvokerServlet. I at first tried the web.xml attached here but it didn't work because that long invokerName value wasn't in JMX... so I truncated it to the part that was: jboss.remoting:service=invoker,transport=servlet
So I try the example and I can tell its talking to the invoker, but it fails and I have no clue what to do. Here's the exception :
java.io.IOException: org.jboss.jms.wireformat.ConnectionFactoryGetClientAOPStackResponse
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at org.jboss.jms.wireformat.SerializedPacket.write(SerializedPacket.java:80)
at org.jboss.jms.wireformat.JMSWireFormat.write(JMSWireFormat.java:237)
at org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(ServletServerInvoker.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
at $Proxy55.processRequest(Unknown Source)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:127)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:156)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:613)
> Add configuration for Remoting servlet transport
> ------------------------------------------------
>
> Key: JBMESSAGING-1131
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1131
> Project: JBoss Messaging
> Issue Type: Task
> Reporter: Ron Sigal
> Assigned To: Tim Fox
> Priority: Minor
> Fix For: Stable branch
>
> Attachments: build.xml, 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list