3 Replies Latest reply on Jan 24, 2005 1:09 PM by 7seconds

    Using different Context inside of a bean

    7seconds

      Hello,

      I hope someone may help me solving my problem.

      I am busy writing a distributed application with this kind of structure:

      I have two jboss servers on two different machines connected via lan: One with a standalone java application as client, both with a jboss4 server containing the same jar containing the same set of ejbs with the same jndi names providing some business functionality. I already set up this scenario and succeeded in communicating with the ejb components in a single jboss server from my client application.

      I set up an InitialContext to connect from my client app to the jboss jnp service this way:

      Properties properties = System.getProperties();
      properties.put("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
      properties.put("java.naming.provider.url", "jnp://localhost:1099");
      properties.put("java.naming.security.principal", "myUserName");
      properties.put("java.naming.security.credentials", "myPassWord");
      InitialContext ctx = new InitialContext(properties);

      and succeeded finding my ejbs using the jndi-names specified in jboss.xml by this code:

      jndiContext = setContext(task.getDSKAddress().getComponentName());
      Object ref = jndiContext.lookup("DSKHomeRemote");
      DSKHomeRemote home = (DSKHomeRemote) PortableRemoteObject.narrow(ref,DSKHomeRemote.class);
      DSKRemote DSK = home.create();

      with task.getDSKAddress().getComponentName() returning the url of the server to connect to via jndi as String with value "jnp://localhost:1099".

      I also succeeded in communincating with the ejbs living in the other jvm jboss located at a remote server from my client app by changing the provider.url to the according setting. I was able to access the Remote objects from the ejbs living in the same jboss container.

      Now, heres my problem:

      if I try to find a bean located on server b from a business method of a bean living in server a, i get this exception:

      16:33:28,923 INFO [STDOUT] java.lang.ClassCastException: javax.naming.CompoundName
      16:33:28,925 INFO [STDOUT] at org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
      16:33:28,926 INFO [STDOUT] at org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
      16:33:28,926 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
      16:33:28,926 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
      16:33:28,926 INFO [STDOUT] at javax.naming.InitialContext.lookup(InitialContext.java:351)
      16:33:28,926 INFO [STDOUT] at redicat.mvs.IMVKBean.executeResourceCollection(IMVKBean.java:84)

      What I did: I created a new Context using the values letting me connect successfully from my client app with this code:

      jndiContext = setContext(task.getDSKAddress().getComponentName());
      Object ref = jndiContext.lookup("DSKHomeRemote");
      DSKHomeRemote home = (DSKHomeRemote) PortableRemoteObject.narrow(ref,DSKHomeRemote.class);
      DSKRemote DSK = home.create();

      with task.getDSKAddress().getComponentName() returning the url of the server to connect to via jndi as String containing "jnp://ip.of.the.server:1009" (replace the ip.of.. with its real ip).

      Now my question: how can I get a reference to the Remote object of a bean living in a jboss server on a jvm on server b from a bean living in a different jboss server in a different jvm on server a?

      Remember: the set of beans living in jboss on server a and b is identical. They were deployed with the same jar file and have the same ejb-jar and jboss.xml files, the same classnames and the same jndi names. The only difference is the machine on which the jboss server runs.

      Is it possible to access beans with the same jndi-name located at different ejb containers? How do I have to set the context to find beans being in container b from a business method of a bean in container a?

      My setup: jboss 4.0.1 linux, configuration out-of-the-box, jdk1.5.0

      Please help, I get nuts if I don't get to solve this problem.

      Greetings from Oldenburg, Germany

      Ralph

        • 1. Re: Using different Context inside of a bean
          frito

          You can explicitly lookup a bean in your server B by creating an new InitialContext(Properties). The URL in these properties should point to server B!

          Wouldn't it be nice to use a jboss cluster and hajndi?

          • 2. Re: Using different Context inside of a bean
            7seconds

            Hello Frito and hello to all the other people,

            I think I didn't mention my case properly: I tried to access the bean of server b from a business method of a session bean residing in server a. The exception I posted was the result of trying to use a new InitialContext, so I was not able to use a newly created InitialContext with URL pointing to server b. But I was successful using a new InitialContext from my client application residing in server a to connect to a bean in server b. My problem is, that a bean inside of server a has to communicate with a bean in server b. Maybe my properties set was incorrect? As I tried to connect from bean a in server a to bean b in server b, I took these properties:

            Properties properties = System.getProperties();
            properties.put("java.naming.factory.initial",
            "org.jnp.interfaces.NamingContextFactory");
            properties.put("java.naming.provider.url", "jnp://ip.of.remote.server:1099");
            properties.put("java.naming.security.principal", "myuser");
            properties.put("java.naming.security.credentials", "mypass");

            Does server a or server b need some configuration changes compared to the configuration out-of-the-box as it was coming with jboss4.0.1 linux tar.bz in order to create a connection to another server? Does default config meet my case or do I have to start both servers with the all configuration? Do I have to create a role in order to connect to the jndi service using the username and password I put into the properties? I am ashamed to ask this question, but I really can't help me out:)...

            You were then speaking about the jboss clustering and hajndi, so here is a new question;) : is it possible to use this setup if the same jar file was deployed to server a and server b? Because of that, the jndi names are identical in both jndi namespaces comparing server a and server b. May one map the jndi context of server b into the namespace of server a? My problem experimenting with jboss clustering so far: as soon as I deploy the ejbset.jar file to server b, the jndi namespace of server a seems to be overwritten resulting in the problem that I am not able to find any bean in server a because of the identical jndi names of the beans in server a and server b. Remember: same jar file deployed.

            I am sorry to ask, and maybe it would be a better place to ask in the newbie forum, but as I reply to you, I post here.

            I already read the jboss4guide (especially chapter 3) and I am not cleverer than before:(

            So, thank You for Your reply and I hope there is someone out there who may bring me to the light of wisdom to create a connection between two beans in tow different servers on two different machines.

            Greetings from Oldenburg, Germany, snowy winter scenario

            Ralph

            • 3. Re: Using different Context inside of a bean
              7seconds

              Hello again,

              because I read something about clustering just a minute ago: I need some message queues on both locations, and I read that jboss doesn't support messageQueue sharing. I already experienced problems trying to deploy the message queues (with the same names) into a cluster-connected server.

              So I think clustering won't be the solution for me, what is more, I need to explicitly address a bean on a server (f.ex. I need to connect to bean xyz on server b, not to any xyzBean somwhere in the cluster).

              Greetings,

              Ralph