5 Replies Latest reply on Mar 5, 2013 10:20 AM by tknyziak

    ejb over jndi from remote client

    robert.geisler

      hello everybody...

       

      i try to find out how to use JNDI for EJB (and JMS!) from a remote (Java) client in JBoss AS 7.1.1.

       

      well, today i am stuck... i already read this and this; i think i know the differences between the JBoss EJB Client API und the Remoting JNDI Client API.
      now i would like to summarize and to discuss the possibilities, their advantages and disadvantages -in respect to our project.

       

      0) we are going to migrate : )

       

      at first i like to say that we are going to migrate an existing Java EE application that is running on JBoss AS 4.2.2 today.
      we tried JBoss 5 and JBoss 6 in the meantime, but never used it in production. now we hope in JBoss 7 and try again : )


      because we want to migrate an existing application we always will prefer a solution that needs as few changes as necessary!
      and it is important that such solutions work for JBoss 4.2.2 and JBoss 7.1.1 at the same time.

       

      1) why not to use the JBoss EJB Client API?


      because of our existing application i thought i should avoid JBoss EJB Client API: because it is a new and JBoss specific API not even JBoss 4.2.2 knows about.
      if we use it, we have to bundle a JBoss 7+ specific library into JBoss 4.2.2. that sounds like an anti pattern to me, doesnt it?

       

      JBoss EJB Client API uses jboss-ejb-client.properties file to establish connections to the server at runtime.
      but our application is running on JBoss installed in our customers local networks. we dont know these networks and its difficult to guess the servers ip address ; )

       

      certainly it could be possible to edit the .properties file while server installation. but our client application is launched through Java Web Start.

      if we edit jars referenced by the JNLP file we have to resign these jars. but resigning at the customers physical server ist not an option of course!

       

      last but not least: our server application uses JMS messages to send requests to clients, so we need remote access to JMS destinations.
      the JBoss EJB Client API doesnt support this yet, right?

       

      2) why use the Remote Naming API?

       

      later i read about the possibility to use the Remote Naming API.

       

      this 'bridge' allows a developer to use the well-known InitialContext with properties at runtime to access remote EJBs.

      the Remote Naming API also supports JMS ConnectionFactories and destinations. that was what i (thought i) searched for ; )

       

      i tried that as it is described here and got a simple example working.

       

      in the next step i tried to integrate this solution into our client application. client startup was successfull and simple functions could be used without any errors.

      but when it comes to multithreading i hit the first problem...

       

      EJBClientContext does not seem to be designed for multithreading as i get "No EJB receiver available for handling" in every thread except the main thread.

      i guess the reason for this exception is, that we create an InitialContext once, put it into a static (global) field and use it widely in the client application.

      within the client modules we lookup remote EJBs through this InitialContext to use the servers functionality.

       

      it seems to me that EJBClientContext via the Remote Naming 'bridge' isnt initialized for a newly created thread!?

      RemoteNamingEjbClientContextSelector.currentContext is a ThreadLocal and that is why an invokation of a proxies method from within a subthread says that it isnt able to find an EJBReceiver!?

       

      is that correct? is it to be expected? by design? or am i doing something wrong??

       

      if it is correct, how am i supposed to initialize this for new threads or more generell: may i use one Context instance in all my client code?
      in the past we experienced a JNDI initial lookup as a heavy operation, so we tried to avoid it as the server connection properties changes rarely...

       

      3) back to JBoss EJB Client API?

       

      is there a solution for the current problem with the Remote Naming API at all? or do you just advise me to use the JBoss EJB Client API instead?

       

      if i have to use JBoss EJB Client API: what are the answers to my questions and doubts in 1)?

      • may we bundle the jboss-ejb-client-1.0.5.Final.jar into JBoss 4.2.2 without any problems?
      • is it possible to not use jboss-ejb-client.properties but configure the properties at runtime??
      • how do we get remote access to JMS resources with this API?

       

       

      well... in the end... an open question:

       

      5) is there any other approach to access ejb and jms from a remote client?? : )

       

       

      thanks in advance!

       

      regards

      robert geisler

        • 1. Re: ejb over jndi from remote client
          wdfink

          Hi Robert,

           

          many questions, only some answers

           

          2)

          The remote naming project is different from AS4/5/6 and also from the new ejb-client API. The behavior is sometimes not what the expectation was.

          Also it is marked as deprecated as it should not be used longer.

           

          3)

          There might be a solution with EJBCLIENT-34 which fit to your problems.

           

          In the meanwhile you might have a look into the quickstarts helloworld-jms or the documentation here.

          If you look into my githup repo you will find also some ejb (client) examples. Hava a look into the ejb-multi-server and ejb-clients branch.

           

          Wolf

          • 2. Re: ejb over jndi from remote client
            robert.geisler

            hi Wolf,

             

            thank you for your quick response and your links.

             

            i took a look at the quickstarts and examples. they are all fine and they might work, but...
            they do not tell me anything about alternatives and best practices in 'complex' applications.

            or did i miss something? 0; )

             

            i took a look at EJBCLIENT-34, too, and votet for it : )
            as long as this is not available i will try PropertiesBasedEJBClientConfiguration.

            maybe this might be a temporary workaround for me... i will let you know!

             

            as i told you, there is an existing application that needs to be migrated.

            thats why the questions concerning different contexts for EJB and JMS and dynamic EJB context configuration are important for me ; )

             

             

            hope to get more input soon : )

             

            regards

            robert

            • 3. Re: ejb over jndi from remote client
              tknyziak

              Hello Robert,

               

              I know the thread is a bit old, but I've found it after a three-day struggle to deal with the dreaded "No EJB receiver available for handling" situation - and I'd like to thank you for the hint that the EJBClientContext might not be thread-safe. I wanted to use remote-naming style of obtaining the EJB interfaces (because my application uses JMS object lookups as well) and spent a hell lot of time trying to figure out why it wouldn't work.

               

              After your suggestion I redesigned my client application to obtain InitialContext instances from a ThreadLocal variable - and BAM! - no more "No EJB receiver..."s.

               

              Thanks again!

               

              Tomasz

              • 4. Re: ejb over jndi from remote client
                jaikiran

                Tomasz Knyziak wrote:

                 

                handling" situation - and I'd like to thank you for the hint that the EJBClientContext might not be thread-safe. I wanted to use remote-naming style of obtaining the EJB interfaces (because my application uses JMS object lookups as well) and spent a hell lot of time trying to figure out why it wouldn't work.

                 

                After your suggestion I redesigned my client application to obtain InitialContext instances from a ThreadLocal variable - and BAM! - no more "No EJB receiver..."s.

                 

                That has nothing to do with thread-safety. It was a bug in remote-naming where you couldn't use a proxy looked up from a different thread, in another thread. I think that has been fixed in latest upstream.

                • 5. Re: ejb over jndi from remote client
                  tknyziak

                  Good to know, I'll comment my hack in the source code as a workaround until the next release shows up. Thanks for the tip!