The servlet invoker is server invoker implementation that uses a servlet running within  a web container to accept initial client invocation requests.  The servlet request is then passed onto the servlet invoker for processing.

The deployment for this particular server invoker is a little different than the other server invokers since a web deployment is also required.  To start, the servlet invoker will need to be configured and deployed.  This can be done by adding the Connector MBean service to an existing service xml or creating a new one.  The following is an example of how to declare a Connector that uses the servlet invoker:

   <mbean code="org.jboss.remoting.transport.Connector"
      xmbean-dd="org/jboss/remoting/transport/Connector.xml"
      name="jboss.remoting:service=Connector,transport=Servlet"
      display-name="Servlet transport Connector">

      <attribute name="InvokerLocator">servlet://localhost:8080/servlet-invoker/ServerInvokerServlet</attribute>

      <attribute name="Configuration">
         <config>
            <handlers>
               <handler subsystem="test">org.jboss.test.remoting.transport.web.WebInvocationHandler</handler>
            </handlers>
         </config>
      </attribute>
   </mbean>

An important point of configuration to note is that the value for the InvokerLocator attribute is the exact url used to access the servlet for the servlet invoker (more on how to define this below), with the exception of the protocol being servlet instead of http.  This is important because if using automatic discovery, this is the locator url that will be discovered and used by clients to connect to this server invoker.

The next step is to configure and deploy the servlet that fronts the servlet invoker.  The pre-built deployment file for this servlet is the servlet-invoker.war file (which can be found in the release distribution or under the output/lib/ directory if doing a source build).  By default, it is actually an exploded war, so the servlet-invoker.war is actually a directory so that can be more easily configured (feel free to zip up into an actual war file if prefer).  In the WEB-INF directory is located the web.xml file.  This is a standard web configuration file and should look like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
   "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
   "http://java.sun.com/dtd/web-app_2_3.dtd">

<!-- The the JBossRemoting server invoker servlet web.xml descriptor -->
<web-app>
    <servlet>
        <servlet-name>ServerInvokerServlet</servlet-name>
        <description>The ServerInvokerServlet receives requests via HTTP
           protocol from within a web container and passes it onto the
           ServletServerInvoker for processing.
        </description>
        <servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
        <init-param>
            <param-name>invokerName</param-name>
            <param-value>jboss.remoting:service=invoker,transport=servlet</param-value>
            <description>The servlet server invoker</description>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>ServerInvokerServlet</servlet-name>
        <url-pattern>/ServerInvokerServlet/*</url-pattern>
    </servlet-mapping>
</web-app>

This file can be changed to meet any web requirements you might have, such as adding security or changing the actual url context that the servlet maps to.  If the url that the servlet maps to is changed, will need to change the value for the InvokerLocator in the Connector configuration mentioned above.  Also note that there is a parameter, invokerName, that has the value of the object name of the servlet server invoker.  This is what the ServerInvokerServlet uses to lookup the server invoker which it will pass the requests onto.

Due to the way the servlet invoker is currently configured an deployed, it must run within the JBoss application server and is not portable to other web servers. 

Exception handling

If the ServletServerInvoker catches any exception thrown from the invocation handler invoke() call, it will send an error to the client with a status of 500 and include the original exception message as it's error message.  From the client side, the client invoker will actually throw a CannotConnectException, which will have root exception as its cause.  The cause should be an IOException with the server's message.  For example, the stack trace from the exception thrown within the test case org.jboss.remoting.transport.servlet.test.ServletInvokerTestClient is:

org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
     at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:154)
     at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:68)
     at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:113)
     at org.jboss.remoting.Client.invoke(Client.java:221)
     at org.jboss.remoting.Client.invoke(Client.java:184)
     at org.jboss.remoting.transport.servlet.test.ServletInvokerTestClient.testInvocation(ServletInvokerTestClient.java:65)
     at org.jboss.remoting.transport.servlet.test.ServletInvokerTestClient.main(ServletInvokerTestClient.java:98)
     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:324)
     at com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/servlet-invoker/ServerInvokerServlet
     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:791)
     at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:139)
     ... 11 more

Issues

One of the issues of using HTTP/Servlet invoker is that the invocation handlers (those that implement ServerInvocationHandler), can not provide very much detail in regards to what is returned in regards to a web context.  For example, the content type used for the

response is the same as that of the request.  Also can not set specific response header values or send specific error status.