Looking at the error stacktrace, the exception appears to be happening on the Glassfish server and not on the JBoss end. Is that correct?
The error is happening at JBOSS end and the request is not reaching at GlassFish
Where does the class com.xchanging.dfv.appsi.remote.serviceinterface._FetchServiceBean_Wrapper lie? Where in your application is the jar containing this class present? Can you post more details about your application packaging?
By the way, i would recommend you try this against JBoss AS 5.1.0 (which is the latest stable version). There have been a lot of changes with EJB3 components since JBoss 4.2.x
The remote interface FetchServiceBean.class is packaged in a jar file which is copied within EAR's lib directory. The hiearchy is:
My application.xml looks like this:
<display-name>dfv-fetch EAR</display-name><library-directory>lib</library-directory>I agree with your suggestion for using JBoss 5.1 but we are using an adobe product which supports only 4.2.x version.
The remote interface FetchServiceBean.class is packaged in a jar file which is copied within EAR's lib directory.
Not the FetchServiceBean.class. I meant the _FetchServiceBean_Wrapper.class. Where is that class located? Going by the name of that class, it appears to be a stub generated by Glassfish, but i am not sure.
Yeah, thats the doubt I have. I think _Wrapper is generated dynamically as we are not creating it. I will check whether this class exists in Glassfish or not.
Not able to see this class anywhere.
I don't know whether in Glassfish the stub generation is static or dynamic. I would recommend that you discuss this exception on the Glassfish forums, since this appears to be a case of the stub not being available in classpath.
I have the same problem in jboss 4.2.3 connecting to glassfish 3.1. Did you find any solution?