Announcement Announcement Module
Collapse
No announcement yet.
Different versions of Spring RMI Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Different versions of Spring RMI

    Hi.

    I need to do RPC between two applications. Iím thinking about using RMI with Spring. The problem is that each application uses a different version of Spring.

    Our application is based on Spring 2.5.x and soon will use 3.0.x

    The other is a third application based on Spring 2.0.x. And I donít know which version of Spring will use in future versions.

    Are versions 2.0.x of Spring-RMI compatible with posterior versions? Which warranties have I for future versions?

    Thanks in advance.

  • #2
    As long as they are compiled with the same JDK they should be in theory compatible. However getting RMI to work between different JDK versions (even minor versions) can be a pain (in my experience). So Spring 3 and Spring 2 aren't going to communicate (or at least making that work has proven difficult).

    So if possible standardize on a spring versions and jdk version if that is problementatic you m ight want to choose a different RPC mechanism.

    Comment


    • #3
      Hi.

      Thanks for your answer.

      Iím using Spring 2.5.4 and the other application uses Spring 2.0.8.

      Both applications runs over the same JDK.

      But our spring-context-2.5.4 was created by 1.6.0_05 (Sun Microsystems Inc.)
      (I have seen it into MANIFEST.MF); and on the third party application, spring-2.0.8.jar was created with 1.5.0_12-b04 (Sun Microsystems Inc.).
      So I will pay attention to your advice, and I will not use jars compiled with different JDKs.

      I will post another thread, open to other technologies.

      Best regards.

      Comment


      • #4
        Hello Marten.

        > As long as they are compiled with the same JDK they should be in theory compatible. However getting RMI to work between different JDK versions (even minor versions) can be a pain (in my experience) Ö

        Sorry. Iím not sure if you are referring to which version of java has been used to create the Spring jars; or which version of rmic compiler will use Spring-RMI.

        In the second case, it should be solved using the same JDK version on both environments.

        Thanks again.

        Comment


        • #5
          Well spring uses rmic of the JDK it is compiled with. So for 2.0 that will be 1.3 for 2.5 that will be 1.4 and for 3. that will be 1.5. I found it quite hard to get a stable RMI environment with different JDK versions, when I did plain RMI myself and also when doing RMI with spring.

          Comment


          • #6
            Thank you very much.

            Comment


            • #7
              Using different versions of spring

              Greetings Folks,

              To know: What are those cases for which different versions of spring in client and Server can create some problems. Could you please list some of the cases/problems etc.

              Summary: Client and server using different versions of spring and cglib jars were able to communicate succesfully using Spring RMI

              Details:
              I created a client (spring 2.5.5, cglib2.1.3) and server (Spring 3.x, cglib2.2) and used Spring RMI to make them communicate. Kept JDK same for both.
              No issues were found.

              Even when server and client were in different JDK then also (after removing Generics, and other java 5 features) no issues were found.

              Although keeping same JDK is not a problem. But I can't control the spring version of server. So could you please enlist where actually I might get issues if the SPring version is different (JDK being at same version). Since thsi will give me an idea if Spring RMI would work in my case or not. Otherwise, I might have to do away with Spring RMI and go back to plain old RMI stuff. (I cant use HTTPinvoker etc there are some other constraints so this has been ruled out).

              Comment

              Working...
              X