This topic has not yet been written. The content below is from the topic description.
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: servlet://localhost:8080/servlet-invoker/ServerInvokerServlet org.jboss.test.remoting.transport.web.WebInvocationHandler 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 if using automatic discovery, as 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 lib directory of 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: ServerInvokerServlet The ServerInvokerServlet receives requests via HTTP protocol from within a web container and passes it onto the ServletServerInvoker for processing. org.jboss.remoting.transport.servlet.web.ServerInvokerServlet invokerName jboss.remoting:service=invoker,transport=servlet The servlet server invoker 1 ServerInvokerServlet /ServerInvokerServlet/* There are two ways in which the servlet can obtain a reference to the servlet server invoker it needs to pass its request onto. The first is by using the param 'invokerName', as is shown above. The value for this should be the JMX ObjectName for the servlet server invoker that was deployed as a service mbean (see service xml above). The other way is to provide a param 'locatorUrl' with a value that matches the locator url of the servlet server invoker to use. In this case, will use the InvokerRegistry to find the server invoker instead of using JMX, which is useful if not deploying server invoker as a mbean service or if want to run in web container other than the JBoss application server. Note, one or the other param is required. If both are provided, the 'locatorUrl' param take precedence. This file can be changed to meet any web requirements you might have, such as adding security (see sslservlet) 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. Note. Prior to Remoting version 2.4, org.jboss.remoting.transport.servlet.ServletServerInvoker generated a single MBean ObjectName for representing ServletServerInvokers as MBeans, which meant that an MBeanServer could be aware of only a single ServletServerInvoker MBean. As of version 2.4, that restriction has been eliminated. Note. Prior to Remoting version 2.4, when org.jboss.remoting.transport.servlet.web.ServerInvokerServlet retrieved an MBeanServer, it looked only for an MBeanServer whose default domain was "jboss". As of version 2.4, the default domain can be configured by adding an "mbeanServer" init-param element to the web.xml file. If the "mbeanServer" value is set to "*platform*" and jdk 1.5 or greater is in use, ServerInvokerServlet will retrieve the platform MBeanServer by calling java.lang.management.ManagementFactory.getPlatformMBeanServer(). In the absence of a configured default domain, ServerInvokerServlet will still use "jboss" as the default domain.