[jboss-user] [JBoss Seam] - Re: WebRemote inconsistencies

[ZeddMaxim]

Ok, so my understanding is still incomplete.  Adding to the remote interface adds the stubs, but does not solve the problem.  Does seam remoting only work with local interfaces?  When the Call class actually invokes the method through reflection, I am getting the following stack trace:

java.lang.IllegalArgumentException: object is not an instance of declaring class
  | 	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.seam.remoting.Call.execute(Call.java:121)
  | 	at org.jboss.seam.remoting.ExecutionHandler.handle(ExecutionHandler.java:92)
  | 	at org.jboss.seam.remoting.SeamRemotingServlet.doPost(SeamRemotingServlet.java:56)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  | 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  | 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  | 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  | 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
  | 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
  | 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
  | 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  | 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  | 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  | 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  | 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  | 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  | 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  | 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
  | 	at java.lang.Thread.run(Thread.java:595)

Also, I noticed this in Call.execute itself:

if (component.getBusinessInterfaces().size() > 0)
  |     {
  |       // Get the local interface for the component - this is the type that we're
  |       // going to assume we're invoking against.
  |       type = component.getBusinessInterfaces().iterator().next();
  |     }

If you're only going after local interfaces, would it make more sense to iterate until you find one with a @Local annotation?  Again, my understanding may be incomplete, and these suggestions may be totally bogus.

My solution for now will be to remove the remote interface.  We had only been using it for testing up to this point.  However, if the time ever comes that they want to expose this bean as a web service, or they want the class to implement another interface, this will again become a problem for me.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962836#3962836

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962836