1 2 Previous Next 18 Replies Latest reply on Oct 28, 2005 9:03 AM by thomas.diesler

    JNDI Lookup returns Reference - causes ClassCastException

    craigpugsley

      Hi there. I'm trying to call our web service using standard code outlined in the examples both in the JBoss wiki and in the Sun tutorials.

      The problem I'm having occurs when I perform a lookup for our registered service using the JBoss-flavoured initial context:

      javax.naming.InitialContext iniCtx = getInitialContext();
      Object obj = iniCtx.lookup("java:comp/env/service/PolicyFileMgrService");
      javax.xml.rpc.Service service = (javax.xml.rpc.Service)iniCtx.lookup("java:comp/env/service/PolicyFileMgrService");
      PolicyFileMgrService policyFileMgrService = (PolicyFileMgrService)service.getPort(PolicyFileMgrService.class);
      policyFileMgr = policyFileMgrService.getPolicyFileMgr();
      


      The error is obviously on the second line where I have broken down the sample provided code to see what object type is returned. It seems I am returned a 'javax.naming.Reference' object, instead of the 'PolicyFileMgrService' I was expecting when I perform the lookup.

      I have been following this thread ('http://www.jboss.com/index.html?module=bb&op=viewtopic&t=54033') and I have tried changing the classpath, without success.

      Some context: I am running my client app from Eclipse on a machine that is remote from the server JBoss is running on. I have implemented application-client.xml and jboss-client.xml, jacrpc mapping files and relevant wdsl file, and deployed these on JBoss next to our application EAR that has the services I would like to access.

      I can see that the services are being bound in the JNDI:

      DEBUG [org.jboss.deployment.MainDeployer] Begin deployment start file:/C:/policymatter/jboss-4.0.3/server/default/deploy/pccAppClient.jar
      DEBUG [org.jboss.deployment.ClientDeployer] Creating client ENC binding under: PolicyControlCentre
      DEBUG [org.jboss.webservice.ServiceClientDeployer] Webservice binding: java:comp/env/service/PolicyFileMgrService
      DEBUG [org.jboss.webservice.ServiceClientDeployer] Webservice binding: java:comp/env/service/PolicyControlCenterService
      DEBUG [org.jboss.deployment.ClientDeployer] Binding resource: ref_pmuploadprogress to JDNI as: null
      DEBUG [org.jboss.deployment.ClientDeployer] Binding resource: ref_pmuploadprogressTCF to JDNI as: null
      DEBUG [org.jboss.deployment.ClientDeployer] Binding resource: ref_pmupload to JDNI as: null
      DEBUG [org.jboss.deployment.ClientDeployer] Binding resource: ref_pmuploadQCF to JDNI as: null
      INFO [org.jboss.deployment.ClientDeployer] Client ENC bound under: PolicyControlCentre
      DEBUG [org.jboss.deployment.MainDeployer] End deployment start on package: pccAppClient.jar
      DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/C:/policymatter/jboss-4.0.3/server/default/deploy/pccAppClient.jar
      


      This is my application-client.xml file:

      <?xml version="1.0" encoding="UTF-8"?>
      <application-client xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd" version="1.4">
       <display-name>PolicyControlCentre</display-name>
       <service-ref>
       <service-ref-name>service/PolicyControlCenterService</service-ref-name>
       <service-interface>javax.xml.rpc.Service</service-interface>
       <wsdl-file>META-INF/wsdl/PolicyControlCenter_jboss.wsdl</wsdl-file>
       <jaxrpc-mapping-file>META-INF/PolicyControlCenter_mapping_jboss.xml</jaxrpc-mapping-file>
       <service-qname xmlns:pfx="http://service.repository.policymatter.com">pfx:PolicyControlCenterService</service-qname>
       <port-component-ref>
       <service-endpoint-interface>com.policymatter.repository.service.PolicyControlCenter</service-endpoint-interface>
       </port-component-ref>
       </service-ref>
       <service-ref>
       <service-ref-name>service/PolicyFileMgrService</service-ref-name>
       <service-interface>javax.xml.rpc.Service</service-interface>
       <wsdl-file>META-INF/wsdl/PolicyFileMgr_jboss.wsdl</wsdl-file>
       <jaxrpc-mapping-file>META-INF/PolicyFileMgr_mapping_jboss.xml</jaxrpc-mapping-file>
       <service-qname xmlns:pfx="http://service.policymatter.com">pfx:PolicyFileMgrService</service-qname>
       <port-component-ref>
       <service-endpoint-interface>com.policymatter.service.PolicyFileMgr</service-endpoint-interface>
       </port-component-ref>
       </service-ref>
       <resource-ref id="ResourceRef_1125059009605">
       <description>
       </description>
       <res-ref-name>ref_pmuploadQCF</res-ref-name>
       <res-type>javax.jms.QueueConnectionFactory</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
       </resource-ref>
       <resource-ref id="ResourceRef_1125059426415">
       <description>
       </description>
       <res-ref-name>ref_pmupload</res-ref-name>
       <res-type>javax.jms.Queue</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
       </resource-ref>
       <resource-ref id="ResourceRef_1125059626576">
       <description>
       </description>
       <res-ref-name>ref_pmuploadprogressTCF</res-ref-name>
       <res-type>javax.jms.TopicConnectionFactory</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
       </resource-ref>
       <resource-ref id="ResourceRef_1125059626585">
       <description>
       </description>
       <res-ref-name>ref_pmuploadprogress</res-ref-name>
       <res-type>javax.jms.Topic</res-type>
       <res-auth>Container</res-auth>
       <res-sharing-scope>Shareable</res-sharing-scope>
       </resource-ref>
      </application-client>
      


      I assume this is correct, because the wsdl I include in the deployed JAR is being picked up at 'http://mymachinename/PolicyServerEJB/PolicyFileMgrPort?wsdl'.

      Looking in the JMX console at the JNDI, I can see the J2EE client service is deployed:

       +- PolicyControlCentre (class: org.jnp.interfaces.NamingContext)
       | +- service (class: org.jnp.interfaces.NamingContext)
       | | +- PolicyControlCenterService (class: org.jboss.webservice.client.ServiceReferenceable)
       | | +- PolicyFileMgrService (class: org.jboss.webservice.client.ServiceReferenceable)
       | +- ref_pmupload[link -> null] (class: javax.naming.LinkRef)
       | +- ref_pmuploadprogressTCF[link -> null] (class: javax.naming.LinkRef)
       | +- ref_pmuploadprogress[link -> null] (class: javax.naming.LinkRef)
       | +- ref_pmuploadQCF[link -> null] (class: javax.naming.LinkRef)
      


      On the classpath, I have only added 'jbossall-client.jar' in addition to the libraries I had been using before. These libraries are:

      xml-apis.jar
      xercesImpl.jar
      wsdl4j-1.5.1.jar
      ui.jar
      Tidy.jar
      servlet.jar
      saaj.jar
      log4j-1.2.8.jar
      jmdns.jar
      jdom.jar
      jazzy-swing.jar
      jazzy-core.jar
      jaxrpc.jar
      jaxen-1.1-beta-4.jar
      jakarta-slide-webdavlib-2.1.jar
      jakarta-slide-commandline-2.1.jar
      jakarta-regexp-1.3.jar
      jacob.jar
      itext-1.3.jar
      fop.jar
      filedrop.jar
      editlivejava.jar
      commons-transaction-1.0.jar
      commons-logging-1.0.4.jar
      commons-lang-2.0.jar
      commons-httpclient-contrib.jar
      commons-httpclient.jar
      commons-discovery-0.2.jar
      castor-0.9.5.3.jar
      batik.jar
      axis-ant.jar
      axis.jar
      avalon-framework-cvs-20020806.jar
      antlr.jar
      AbsoluteLayout.jar
      jbossall-client.jar
      


      Previously, we were simply calling the web services via generated proxy objects, but we are looking to move our Java Swing application into a proper J2EE application client and look up dynamic proxies via JNDI.

      Any help on this problem would be much appreciated! I'm frantically trying to keep the JBoss flame alive in our organisation, where everyone else seems to want to jump-ship to commercial app servers. Please help me show them that a complex J2EE app client is feasible!

      Thanks.

        • 1. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
          starksm64

          You are either missing the correct object factory setting in jndi.properties, or missing classes needed by the jndi object factory. The jndi.properties/env may need to contain a java.naming.factory.url.pkgs=org.jboss.naming.client:org.jboss.naming:org.jnp.interfaces setting.

          • 2. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
            craigpugsley

             

            "scott.stark@jboss.org" wrote:
            ... The jndi.properties/env may need to contain a java.naming.factory.url.pkgs=org.jboss.naming.client:org.jboss.naming:org.jnp.interfaces setting.

            After finding and changing the 'jndi.properties' file in JBoss/server/default/conf/, I find that now, certain jndi names aren't binding and my application isn't start at all.

            I then tried simply swapping the ordering of the packages in the jndi.properties file from:
            java.naming.factory.url.pkgs=org.jboss.naming.client:org.jboss.naming:org.jnp.interface
            

            to
            java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces:org.jboss.naming.client
            

            and now, at least, my application launches again.

            However, I'm still no closer than I was before. I can still see the JNDI name bound in the JNDI (as described previously), and performing the lookup call still returns a Reference object instead of my PolicyFileMgrService object.

            I've tried adding the libraries described in JBossWSFAQ wiki page:

            ...build.xml from the samples.zip
             <path id="client.classpath">
             <fileset dir="${jboss.home}/client">
             <include name="activation.jar"/>
             <include name="axis-ws4ee.jar"/>
             <include name="commons-discovery.jar"/>
             <include name="commons-logging.jar"/>
             <include name="jbossall-client.jar"/>
             <include name="jboss-saaj.jar"/>
             <include name="jboss-jaxrpc.jar"/>
             <include name="jboss-ws4ee-client.jar"/>
             <include name="log4j.jar"/>
             <include name="namespace.jar"/>
             <include name="wsdl4j.jar"/>
             </fileset>
             </path>
            


            But this just seems to leave me with naming exception errors and class cast exceptions, probably brought about due to class path clashes between the old libs I had to get from a JBoss previous to the 403 I'm using now.

            You mention that I could be 'missing classes needed by the jndi object factory'. Is this on the client-side? Which libraries are these?

            • 3. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
              starksm64

              Display the Reference.getFactoryClassName() to find out what object factory is the starting point for the missing classes.

              • 4. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                craigpugsley

                 

                "scott.stark@jboss.org" wrote:
                Display the Reference.getFactoryClassName() to find out what object factory is the starting point for the missing classes.

                The object factory is 'org.jboss.webservice.client.ServiceObjectFactory'. I'm sorry, but how does this help me determine what libraries are missing? AFAIK, this is just telling me the object factory that is doing the looking up, not what it is actually looking up.

                Looking up the JavaDocs for this package tells me this about the 'ServiceObjectFactory':

                This ServiceObjectFactory reconstructs a javax.xml.rpc.Service for a given WSDL when the webservice client does a JNDI lookup

                It uses the information provided by the service-ref element in application-client.xml


                Looking back at my application-client.xml file, I see nothing wrong with the service-ref elements as far as I can see. The only difference is the 'service-interface' element.

                In the example application-client.xml file on your WSClientAppl wiki page, the 'service-ref' looks like this:

                <service-ref>
                 <service-ref-name>service/OrganizationServiceEJB</service-ref-name>
                 <service-interface>javax.xml.rpc.Service</service-interface>
                 <wsdl-file>META-INF/wsdl/server-ejb.wsdl</wsdl-file>
                 <jaxrpc-mapping-file>META-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
                 </service-ref>
                
                 <service-ref>
                 <service-ref-name>service/OrganizationServiceJSE</service-ref-name>
                 <service-interface>com.underworld.crimeportal.OrganizationEndpointService</service-interface>
                 <wsdl-file>META-INF/wsdl/server-web.wsdl</wsdl-file>
                 <jaxrpc-mapping-file>META-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
                 </service-ref>


                Whereas, mine looks like this (re-quoted from original post):

                <service-ref>
                 <service-ref-name>service/PolicyControlCenterService</service-ref-name>
                 <service-interface>javax.xml.rpc.Service</service-interface>
                 <wsdl-file>META-INF/wsdl/PolicyControlCenter_jboss.wsdl</wsdl-file>
                 <jaxrpc-mapping-file>META-INF/PolicyControlCenter_mapping_jboss.xml</jaxrpc-mapping-file>
                 <service-qname xmlns:pfx="http://service.repository.policymatter.com">pfx:PolicyControlCenterService</service-qname>
                 <port-component-ref>
                 <service-endpoint-interface>com.policymatter.repository.service.PolicyControlCenter</service-endpoint-interface>
                 </port-component-ref>
                </service-ref>
                <service-ref>
                 <service-ref-name>service/PolicyFileMgrService</service-ref-name>
                 <service-interface>javax.xml.rpc.Service</service-interface>
                 <wsdl-file>META-INF/wsdl/PolicyFileMgr_jboss.wsdl</wsdl-file>
                 <jaxrpc-mapping-file>META-INF/PolicyFileMgr_mapping_jboss.xml</jaxrpc-mapping-file>
                 <service-qname xmlns:pfx="http://service.policymatter.com">pfx:PolicyFileMgrService</service-qname>
                 <port-component-ref>
                 <service-endpoint-interface>com.policymatter.service.PolicyFileMgr</service-endpoint-interface>
                 </port-component-ref>
                </service-ref>


                ...the difference being the 'service-interface' elements are 'javax.xml.rpc.Service' for the 'OrganizationServiceEJB' and 'com.underworld.crimeportal.OrganizationEndpointService' for the 'OrganizationServiceJSE' - whereas mine are 'javax.xml.rpc.Service' for both.

                I'll investigate this next and see what happens.

                If this doesn't make a difference, do you think the classes I'm missing are my own classes on the server-side, or some JBossWS classes on the client side?

                • 5. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                  craigpugsley

                   

                  "craigpugsley" wrote:

                  ...the difference being the 'service-interface' elements are 'javax.xml.rpc.Service' for the 'OrganizationServiceEJB' and 'com.underworld.crimeportal.OrganizationEndpointService' for the 'OrganizationServiceJSE' - whereas mine are 'javax.xml.rpc.Service' for both.

                  I'll investigate this next and see what happens.

                  I changed my application-client.xml to point to our class, and I get the same behaviour. No change.

                  Do you think the classes I'm missing are my own classes on the server-side, or some JBossWS classes on the client side?

                  What am I doing that is so deviant from the standard way of doing J2EE app clients? Why doesn't this just work?

                  • 6. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                    starksm64

                    The client in missing the classes starting with the org.jboss.webservice.client.ServiceObjectFactory which is not in the jbossall-client.jar for some reason. Its in the jboss-ws4ee-client.jar:

                    [starksm@banshee9100 client]$ jar -tf jbossall-client.jar | grep ServiceObjectF
                    actory
                    [starksm@banshee9100 client]$ for j in *.jar
                    > do
                    > echo $j
                    > jar -tf $j | grep ServiceObjectFactory
                    > done
                    activation.jar
                    avalon-framework.jar
                    axis-ws4ee.jar
                    commons-discovery.jar
                    commons-logging.jar
                    concurrent.jar
                    ejb3-persistence.jar
                    getopt.jar
                    hibernate-annotations.jar
                    hibernate-client.jar
                    jacorb.jar
                    javax.servlet.jar
                    jboss-annotations-ejb3.jar
                    jboss-aop-jdk50-client.jar
                    jboss-aspect-jdk50-client.jar
                    jboss-client.jar
                    jboss-common-client.jar
                    jboss-deployment.jar
                    jboss-ejb3-client.jar
                    jboss-ejb3x.jar
                    jboss-iiop-client.jar
                    jboss-j2ee.jar
                    jboss-jaxrpc.jar
                    jboss-jsr77-client.jar
                    jboss-remoting.jar
                    jboss-saaj.jar
                    jboss-system-client.jar
                    jboss-transaction-client.jar
                    jboss-ws4ee-client.jar
                    org/jboss/webservice/client/ServiceObjectFactory.class
                    jbossall-client.jar
                    jbosscx-client.jar
                    jbossha-client.jar
                    jbossjmx-ant.jar
                    jbossmq-client.jar
                    jbosssx-client.jar
                    jmx-client.jar
                    jmx-invoker-adaptor-client.jar
                    jnp-client.jar
                    juddisaaj.jar
                    log4j.jar
                    logkit.jar
                    mail.jar
                    namespace.jar
                    scout.jar
                    wsdl4j.jar
                    



                    • 7. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                      craigpugsley

                      Great. So now I have 'jbossall-client.jar' and 'jboss-ws4ee-client.jar' on my classpath along with all the other JARs I've listed in earlier post.

                      I now get a different exception when I try to lookup the JNDI reference:

                      javax.naming.NamingException: Cannot unmarshall service ref meta data, cause: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -6756054858541526837
                       at org.jboss.webservice.client.ServiceObjectFactory.getObjectInstance(ServiceObjectFactory.java:114)
                       at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:301)
                       at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1110)
                       at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1127)
                       at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:690)
                       at org.jboss.naming.client.java.javaURLContextFactory$EncContextProxy.invoke(javaURLContextFactory.java:120)
                       at $Proxy0.lookup(Unknown Source)
                       at javax.naming.InitialContext.lookup(InitialContext.java:347)


                      There doesn't seem to be any mention of this exception in this JBossWS forum, but I did come across an interesting thread:

                      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70738

                      ...where:

                      "jason.greene@jboss.com" wrote:
                      Currently the J2EE application client jar has to be deployed on the same system as the standalone client app. This means in the current release, you need to have a minijboss running on the client system. We are going to add support for remote client access in 4.0.4.

                      http://jira.jboss.org/jira/browse/JBWS-438

                      Does this mean I'm banging my head against a brick wall here, as support for client/server separation of J2EE Application Clients in JBoss isn't going to be properly supported (i.e. with remote clients) until 4.0.4?

                      • 8. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                        thomas.diesler

                        No, it just means that you should use the same jboss version for the container that you deploy your application-client and your client code.

                        e.g. you cannot deploy your application-client to 4.0.3 if the apllication that does the jndi lookup runs on 4.0.2 jars

                        • 9. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                          craigpugsley

                          OK, I am using 4.0.3 JARs on the client side with 4.0.3 JBoss. Good.

                          However, I'm still no further forward with this. I don't even understand this error message (posted on 18th Oct), let alone how to resolve it. There doesn't seem to be anything in the forums or wikis mentioning this exception.

                          The mention of serial version IDs, however, suggests to me something to do with differing versions of the serialisation/deserialisation classes?

                          I'm confused and in need of someone to shine a torch over this. I think this is important information that, when we've resolved it, would be worth adding to your wiki pages to help other perilous travellers trying to implement client apps cross-appserver-platform.

                          • 10. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                            starksm64

                            The serialverion of the QName class makes no sense. The value bundled in jdk5 is:

                            [starksm@banshee9100 bin]$ serialver javax.xml.namespace.QName
                            javax.xml.namespace.QName: static final long serialVersionUID = 4418622981026545151L;

                            The -6756054858541526837 matches no version I know of. Values you would see when using jdk1.4.x with jboss are:

                             /** @since 4.0.2, compatible with j2ee1.4 by default */
                             final static long serialVersionUID;
                             static
                             {
                             if (SerialVersion.version == SerialVersion.LEGACY)
                             serialVersionUID = 8217399441836960859L;
                             else
                             serialVersionUID = -3852060120346905000L;
                             }
                            


                            You need to track down the source of the bogus -6756054858541526837 value.

                            • 11. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                              mka

                              Hi Craig,
                              I'm experiencing the same problem that you are, and have been for a while now. Here is what the examples on the wiki neglect to mention:

                              A stand-alone client cannot execute the code posted there without having JBOSS running locally (i.e. on the same machine). Once you assume this architecture to be ideal for your situation (definitely not ideal for me), go ahead and deploy the j2ee client jar just as the wiki suggests, but make sure your stand-alone client and jboss running the j2ee client jar are actually on the same computer. Your stand-alone client should then pull the WS artefacts off the local JNDI, and execute them locally. The work of connecting to your remote web service, running on a different computer with yet another instance of JBOSS, will be performed by the j2ee client jar on your local JBOSS instance. Sounds convoluted? I agree. Looks like an academic exercise? I agree. Not something you'd exactly present to a customer who wants to run your stand-alone client, right?

                              To work around this I've spent sleepless nights trying all sorts of configurations to get a true stand-alone client without the need for a JBOSS install on a client machine. My stand-alone client is deployed via JWS, as a requirement. So obviously deploying JBOSS at each download of the client is out of the question. In this dark, obscure and lonely quest, I've experienced the classcastexception issues you've come across. The classcast exceptions are probably because you have jwsdp jars in your classpath, particularly the jaxrpc ones, as well as Jboss jars. The client runtime seems to get confused between sun and jboss based classes at so many different levels that it's easier to simply isolate the two types of jars.

                              You might say lets cast the darn things, but trust me, if you intend to actually spend your developing your application, isolate the files one by one. Run your app with either JBOSS or Sun jars. There will be one or two sun classes that you cannot do without as your classloader complains, but pick them out of the jar and stick them in a new sanitized jar. I tried running just Sun based jars for my app, got some different type of problem, so now I'll try and run against just the JBOSS based jars, with a few selective Sun classes.

                              I've read the responses that talk about the bane of using implementation specific solutions for the stand-alone client. Guess what folks, my customers do not really care whether or not the stand-alone client is J2EE compliant or not. The interoperability thing is cool, but if we have to include JBOSS on every single client computer to get the thing to work, how can this be a portable solution?

                              • 12. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                                craigpugsley

                                mka, I cannot even begin to thank you for what is probably the first (or at least most) straight answer I've had in these two pages of thread.

                                Do you have an idea of what point the remote calls fail, and must be done against a local JBoss (talking to the remote JBoss)? Is it that a remote JBoss just isn't able to provide web service artifacts to an app client running locally from a remote JNDI call? And that it can only provide these artifacts locally?

                                You are very clear when you say:

                                "mka" wrote:
                                Hi Craig,
                                A stand-alone client cannot execute the code posted there without having JBOSS running locally (i.e. on the same machine).


                                And my thinking was thrown out when I mentioned previously:
                                "craigpugsley" wrote:
                                [coming] across an interesting thread:

                                http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70738

                                ...where:

                                "jason.greene@jboss.com" wrote:

                                Currently the J2EE application client jar has to be deployed on the same system as the standalone client app. This means in the current release, you need to have a minijboss running on the client system. We are going to add support for remote client access in 4.0.4.

                                http://jira.jboss.org/jira/browse/JBWS-438


                                Does this mean I'm banging my head against a brick wall here, as support for client/server separation of J2EE Application Clients in JBoss isn't going to be properly supported (i.e. with remote clients) until 4.0.4?

                                ...which I think sounds pretty unequivocal. I'm clearly asking there whether talking to a remote JBoss without a local JBoss is possible.

                                To which the reply was:
                                "jason.greene@jboss.com" wrote:

                                No, it just means that you should use the same jboss version for the container that you deploy your application-client and your client code.

                                e.g. you cannot deploy your application-client to 4.0.3 if the apllication that does the jndi lookup runs on 4.0.2 jars


                                ..and I assumed at the time this meant that all I needed to do was make sure I had library version parity on both the local client and remote JBoss.

                                Reading this last quote from Jason Greene back now, however ("you should use the same jboss version for the container that you deploy your application-client"), it looks like he's talking about the local JBoss I need to have running ("the container").

                                This is all very confusing for someone who is relatively new to J2EE development, and the fact that no one seems to want to say "yes, you actually need a local JBoss running to talk to your remote JBoss" in any of the wikis, or even explicitly on this thread, just adds to this confusion.

                                So, can I ask where you are at with this now? Are you sorting your libraries into a sanitised JAR, then biting the bullet and deploying a local JBoss? We, too, deploy via JWS and this has been a very successful course when using WebSphere (the commercial app server we're porting to - see my previous comments to see why I'm even here), as WebSphere actually deploys an application client application container to the local client via JWS from the remote WebSphere first, then your application client is deployed in the normal JWS manner. I would assume this app client app container is equivalent to the 'minijboss' Jason Green talks about, and against which the JNDI calls are made.

                                Once again, thanks very much for taking the time to recount your experiences. Your elucidation is much appreciated, and I'm sure this will help many countless others.

                                • 13. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                                  craigpugsley

                                  Here's another question for anyone:

                                  if I'm calling the local JNDI on the local JBoss, how does the local JBoss know where to look for the remote JBoss with the actual EJBs and services running?

                                  • 14. Re: JNDI Lookup returns Reference - causes ClassCastExceptio
                                    starksm64

                                    This dicussion of needing a local jboss instance is completely false. You need the jboss jars only.

                                    1 2 Previous Next