6 Replies Latest reply: Dec 13, 2005 8:17 PM by Erik Westland RSS

    how to statically generate ejb stubs

    jlsredondo Newbie

      I'm trying to run jboss client libraries from .Net using IKVM. So far, i've been able to compile all the jboss client jars to .Net dlls (using ikmvc) and the EJB jar i'm using as an example.

      When it comes to develop a client (in this case using C#), i proceed as usual, that is, contacting the naming service, getting a home reference and creating the bean. When i run the example, an exception is raised indicanting a failure when retrieving stubs from the server.

      I think the problem is related to the fact that in Jboss the EJB stubs are generating on the fly and the client automatically downloads them on demand. However, this behaviour causes problems with IKVM since this library needs all the java classes in advance in order to compile them to .Net assemblies. This problem would be solved if the java classes for the EJB stubs (home and remote interface) could be statically generated.

      So my question is whether it's possible to statically generate EJB stubs in Jboss so that they can be compiled to .Net assemblies in this case.


        • 1. Re: how to statically generate ejb stubs
          Darran Lofthouse Master

          Have you considered using web services?

          • 2. Re: how to statically generate ejb stubs
            jlsredondo Newbie

            Web services ? You must be joking !
            Our scenario is a number of .Net clients an a Jboss server in a LAN, so our last option is to use Web services.

            • 3. Re: how to statically generate ejb stubs
              Darran Lofthouse Master

              I think I am missing something here, why can't your .NET clients access web services?

              • 4. Re: how to statically generate ejb stubs
                Scott Stark Master

                There are no ejb stubs as we use dynamic proxies using the java.lang.reflect.Proxy mechanism. Show the exception you are seeing.

                • 5. Re: how to statically generate ejb stubs
                  jlsredondo Newbie

                  this is the exception message i'm seeing:

                  Failed to retrieve stub from server

                  And this is the stack trace:
                  at org.jnp.interfaces.NamingContext.discoverServer(Hashtable )
                  at org.jnp.interfaces.NamingContext.checkRef(Hashtable )
                  at org.jnp.interfaces.NamingContext.lookup(Name )
                  at org.jnp.interfaces.NamingContext.lookup(String )
                  at javax.naming.InitialContext.lookup(String )
                  at clientedotnet.Class1.Main(String[] args) in c:\proyectos\ikvm\clientedotnet.exe

                  The exception message "Failed to retrive stub from server" is located in the file org.jnp.interfaces.NamingContext, method getServer:

                  try {

                  // Get stub from naming server
                  BufferedInputStream bis = new BufferedInputStream(s.getInputStream());
                  ObjectInputStream in = new ObjectInputStream(bis);
                  MarshalledObject stub = (MarshalledObject) in.readObject();
                  server = (Naming) stub.get();

                  // Add it to cache
                  addServer(hostKey, server);
                  serverEnv.put("hostKey", hostKey);

                  return server;
                  catch(IOException e)
                  NamingException ex = new CommunicationException("Failed to retrieve stub from server "+hostKey);
                  throw ex;

                  Any idea on this exception ?

                  I'm using Jboss 3.2.5

                  Thanks in advance

                  • 6. C#/ikvm JBoss client naming service hang (was: how to static
                    Erik Westland Newbie

                    Scott et al,

                    First off, I can not help you solve this (year old) issue. I am groveling for your/someone's help on getting a simple C# client (via iKVM) to connect to JBoss (ultimately JBossMQ). You were able to contact the naming service, so you got further than I have. Hopefully you can share your wisdom...

                    When I try my C#/ikvm port it hangs during "lookup" requests on the InitialContext.. I can run the same Java (JRE 1.5) sample program (http://wiki.jboss.org/wiki/Wiki.jsp?page=QueueExample) against my (local) JBoss installation, so it is configured properly.

                    Note: The C# client is contacting the JBoss instance, because if I change the port it throws a connection exception.

                    Compiling jboss-client.jar as follows resulted in a bunch of warnings (gulp), but no errors:
                    ikvmc -out:jbossall-client.jar.dll ./client/jbossall-client.jar

                    I was concerned with that the notation necessary for the inline setup of the properties:
                    properties.put(javax.naming.Context.__Fields.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");

                    So, I hand loaded the properties to ensure they were populated properly:
                    Properties properties = new Properties();
                    FileInputStream fis = new FileInputStream(new java.io.File("./jndi.properties"));
                    InitialContext ctx = new InitialContext(properties);

                    // Go grab lunch, cause I am going to take a VERY long nap...
                    Queue queue = (Queue) ctx.lookup("queue/testQueue");


                    I have seen this issue mentioned elsewhere (e.g. http://lists.gnu.org/archive/html/bug-classpath/2005-10/msg00281.html), but since you seem to have solved/avoided the problem, I figured I would start here...

                    Versions used:
                    JBoss: 4.0.3SP1 (JRE 1.5.0_05-b05, tried 1.4.2 as well)
                    C#/.Net: 1.1.4

                    Cheers and thanks,

                    P.S. I was successful using ActiveMQ (with ikvm), but JBossMQ's management features are more important to me than performance. Maybe I should reassess my evaluation criteria...