I'm trying to use the "restricted" http invoker (on AS 6.1 Final) for a remote client and am having some difficulties.

In server/<whatever>/deploy/httpa-invoker.sar/invoker.war/WEB-INF/web.xml I've commented out all the servlet-mappings except for those for /restricted/JNDIFactory/* and /restricted/JMXInvokerServlet/*.

In my client application I setup the properties for my InitialContext like this:

{code}
Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.HttpNamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
env.setProperty(Context.PROVIDER_URL, "http://" + serverIP + "/invoker/restricted/JNDIFactory");
{code}

Since the restricted invoker requires authentication I also use a CallbackHandler and LoginContext as part of creating the InitialContext.

When I run the client app and sniff the network traffic to JBoss I can see that the client program first tries to post to the invoker servlet and receives an authentication required message. It immediately turns around and tries the same post using basic auth, which succeeds. But when it does the lookup of the object in JNDI (looking up a JMS topic in my case) the program throws an error:

{noformat}
Exception trying to setup JMS connection:Operation failed
javax.naming.CommunicationException: Operation failed [Root exception is java.rmi.ServerException: IOE; nested exception is: 
        java.io.FileNotFoundException: http://192.168.1.11/invoker/JMXInvokerServlet]
        at org.jboss.naming.interceptors.ExceptionInterceptor.invoke(ExceptionInterceptor.java:65)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
        at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
        at $Proxy0.lookup(Unknown Source)
        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at com.foo.tools.LogMessageClient.setupJMS(LogMessageClient.java:91)
        at com.foo.tools.LogMessageClient.<init>(LogMessageClient.java:66)
        at com.foo.tools.LogMessageClient.main(LogMessageClient.java:48)
Caused by: java.rmi.ServerException: IOE; nested exception is: 
        java.io.FileNotFoundException: http://192.168.1.11/invoker/JMXInvokerServlet
        at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:133)
        at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
        at org.jboss.naming.interceptors.ExceptionInterceptor.invoke(ExceptionInterceptor.java:57)
        ... 10 more
Caused by: java.io.FileNotFoundException: http://192.168.1.11/invoker/JMXInvokerServlet
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1434)
        at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:178)
        at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:118)
        ... 13 more
 
{noformat}

At this point I tried a number of things that worked (I'll explain below), but I'm not sure if my workarounds are correct or if I'm getting unexpected behavior from the invoker (or perhaps its just a config issue?).

My first test was to go in and un-comment out the non-restricted invokers that I had previously commented out in server/<whatever>/deploy/httpa-invoker.sar/invoker.war/WEB-INF/web.xml. This worked, but I imagine this also exposed the invokers in a way without any authentication, so I don't really like this solution.

Related to the test above, I think another option would be to just add all the servlet mappings (or just the servlets themselves) into the security constraint in the web.xml so that they were all treated like the "restricted" invoker. I didn't actually test that route, but it seems like it would work.

My second test was change the web.xml back to only having the mapping for the restricted invoker, and then to edit server/<whatever>/deploy/httpa-invoker.sar/META-INF/jboss-service.xml. I noticed this file had configs for the read-only invoker and main invokers, but nothing for the restricted ones. I started in this file by copying the section that exposed the naming service and pasting it back into the file. In the pasted section I changed:

{code:xml}
<mbean code="org.jboss.invocation.http.server.HttpProxyFactory"
      name="jboss:service=invoker,type=http,target=Naming,restricted=true">
....
        <value-factory bean="ServiceBindingManager" method="getStringBinding">
           <parameter>jboss.web:service=WebServer</parameter>
           <parameter>HttpConnector</parameter>
           <parameter>http://${hostforurl}/invoker/restricted/JMXInvokerServlet</parameter>
        </value-factory>
{code}

So I added the 'restricted=true' to the mbean tag because jboss complained about duplicate names on startup without it. And then there was the change to the URL to add restricted to the path. Unfortunately this made no difference.

Next attempt was to remove that pasted section and just change the original naming service section to use the 'restricted' URL instead of the plain one. After making that change (still with only having the restricted invokers mapped in the web.xml file) my client program has no problem connecting and doing JNDI lookups.

At this point I've got a couple of options that I can use to get things working, but I'd appreciate any feedback or advice anyone may have on how the invoker is designed to work and what approach would be best. Thanks!

Chris