6 Replies Latest reply on Nov 16, 2004 7:45 AM by thomas.diesler

    Axis EJB provider not registered with JBoss 3.2.6

    mjea

      Hi,

      I try to call an EJB from a client using axis web services. So I defined java:EJB as the Axis provider. All this work fine with JBoss 3.2.3. But I decided to switch to 3.2.6 and I have this kind of errors:

      No provider type matches QName '{http://xml.apache.org/axis/wsdd/providers/java}EJB'

      So I had a look at the definition of providers. This is what we have in 3.2.3:


      static {
       providers.put(WSDDConstants.QNAME_JAVARPC_PROVIDER, new WSDDJavaRPCProvider());
       providers.put(WSDDConstants.QNAME_JAVAMSG_PROVIDER, new WSDDJavaMsgProvider());
       providers.put(WSDDConstants.QNAME_HANDLER_PROVIDER, new WSDDHandlerProvider());
       providers.put(WSDDConstants.QNAME_EJB_PROVIDER, new WSDDJavaEJBProvider());
       providers.put(WSDDConstants.QNAME_COM_PROVIDER, new WSDDComProvider());
       providers.put(WSDDConstants.QNAME_BSF_PROVIDER, new WSDDBsfProvider());
       providers.put(WSDDConstants.QNAME_CORBA_PROVIDER, new WSDDJavaCORBAProvider());
       providers.put(WSDDConstants.QNAME_RMI_PROVIDER, new WSDDJavaRMIProvider());
       try {
       loadPluggableProviders();
       } catch (Throwable t){
       String msg=t + JavaUtils.LS + JavaUtils.stackToString(t);
       log.info(Messages.getMessage("exception01",msg));
       }
       }
      


      and this is what we have in 3.2.6:


      static
       {
       providers.put(WSDDConstants.QNAME_JAVARPC_PROVIDER, new WSDDJavaRPCProvider());
       providers.put(WSDDConstants.QNAME_JAVAMSG_PROVIDER, new WSDDJavaMsgProvider());
       providers.put(WSDDConstants.QNAME_HANDLER_PROVIDER, new WSDDHandlerProvider());
       providers.put(WSDDConstants.QNAME_COM_PROVIDER, new WSDDComProvider());
       try
       {
       loadPluggableProviders();
       }
       catch (Throwable t)
       {
       String msg = t + JavaUtils.LS + JavaUtils.stackToString(t);
       log.info(Messages.getMessage("exception01", msg));
       }
       }
      


      The EJBProvider is not loaded, and I think this is why I can't call EJB's from web services anymore. Is this a normal situation, or did I miss something ? Do we have to call EJB's differently now ?

      Thanks for your help.

      Maxime

      PS: for testing purposes, I created a simple web service with 1 dummy method in a session EJB using JBuilder X with JBoss 3.2.x configuration, but I get the same behaviour.



        • 1. Re: Axis EJB provider not registered with JBoss 3.2.6
          thomas.diesler

          Thank you.

          I replaced the old handler

          <!--service name="WSTest" type="" regenerateElement="true"
           provider="java:EJB" style="rpc" use="encoded">
           ...


          by

          <service name="WSTest" type="" regenerateElement="true"
           provider="Handler" style="rpc" use="encoded">
           <parameter name="handlerClass" value="org.jboss.net.axis.server.EJBProvider"/>
           ...
          

          and it works much better.

          I just want to say that the code using the java:EJB provider was generated by JBuilder. It seems JBuilder uses the standard Axis handler even when we are stating JBoss as application server. So the modification must be made manually for every web service meant to run into JBoss. I assume this should be automatic so I'll report this issue to Borland shortly.
          Thanks for your comment.



          • 2. Re: Axis EJB provider not registered with JBoss 3.2.6
            thomas.diesler

            The Axis generic EJB provider cannot be used inside Axis. Stick to the JBoss.NET way of specifying a provider.

            • 3. Re: Axis EJB provider not registered with JBoss 3.2.6
              thomas.diesler

              Sorry, inside JBoss I mean.

              • 4. Re: Axis EJB provider not registered with JBoss 3.2.6
                mjea

                Thank you.

                I replaced the old handler

                <!--service name="WSTest" type="" regenerateElement="true"
                 provider="java:EJB" style="rpc" use="encoded">
                 ...


                by

                <service name="WSTest" type="" regenerateElement="true"
                 provider="Handler" style="rpc" use="encoded">
                 <parameter name="handlerClass" value="org.jboss.net.axis.server.EJBProvider"/>
                 ...
                

                and it works much better.

                I just want to say that the code using the java:EJB provider was generated by JBuilder. It seems JBuilder uses the standard Axis handler even when we are stating JBoss as application server. So the modification must be made manually for every web service meant to run into JBoss. I assume this should be automatic so I'll report this issue to Borland shortly.
                Thanks for your comment.



                • 5. Re: Axis EJB provider not registered with JBoss 3.2.6
                  mjea

                  Tell me if I'm wrong, but there are some features I need that are missing in WS4J:

                  - web service session: we have a complex and costly login phase to determine the user profile. This phase is much more complex than what the J2EE security mechanisms offer. This is done by an Axis handler that calls an external native process. This profile (along with other user related info) must be stored in a session to avoid computing it again and again.

                  - stateful EJB endpoint: the clients must be able to rollback some actions in some case. So we provide transactional support. This can only be achieved by using stateful EJB's, I think.

                  • 6. Re: Axis EJB provider not registered with JBoss 3.2.6
                    thomas.diesler

                    Correct, WS4EE is inherently stateless. This is because not every transport offers session maintanace. There are proposals under way to standardize the session maintanace at message level, which then would be transport independent.

                    What one usually does is introduce an application specific header that contains the client's session id. The client then still talkes to a staless endpoint, which extracts the SOAP header and routes the request to a stateful component, i.e. SFSB