Announcement Announcement Module
No announcement yet.
Merge ApplicationContext with separate ClassPaths Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Merge ApplicationContext with separate ClassPaths

    Hi All.
    Possible question like this already present in forum but I haven't found it (refer me if it exist).

    I want create a tool that very similiar to EJB.

    We have a lot of modules , that uses Spring. But communication betweeen modules now still old plain EJB.

    So what we want do :

    - Define for every applicationConext (e.g every module that we have) an a "remote interface" (aka EJB).

    - Load all application context (Reading forum I understand that we need use SingletonBeanFactoryLocator).

    - we not need merging of these beans .

    - from one applicationContext we want have an a reference to other applicationContext via remote interface. (In other words - ref-bean - but bean will be defined in other context).

    - Our problem in that we use Different Version of libraryies - so we requry different class loaders for EVERY context.

    Thank all.

    Any info will helpfull.

    P.S. Sorry for my basic English.

  • #2
    I was going to recommend the use of "RmiProxyFactoryBean" (See chapter 17 of reference manual) would be useful here. But, now I think that won't be useful. Could an application context itself be proxied too?

    -- Josef
    Last edited by jbetancourt; Jul 24th, 2006, 07:22 AM.


    • #3
      Originally posted by jbetancourt
      You can try "RmiProxyFactoryBean". See chapter 17 of reference manual.

      -- Josef
      Thank you Josef for your reply,
      But we want remove RMI communication (it is sense why we remove EJB integration).

      I have found EL4J library. It looks for me that it will be good for our purpose. I will write my feedback on it - if this library will be helpfull.


      • #4
        EL4J is an interesting project. Thanks for the link.

        Note that the remoting support in Spring includes non-RMI approaches too, from ref manual:

        Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).

        Spring's HTTP invoker. Spring provides a special remoting strategy which allows for Java serialization via HTTP, supporting any Java interface (just like the RMI invoker). The corresponding support classes are HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter.

        Hessian. By using the HessianProxyFactoryBean and the HessianServiceExporter you can transparently expose your services using the lightweight binary HTTP-based protocol provided by Caucho.

        Burlap. Burlap is Caucho's XML-based alternative for Hessian. Spring provides support classes such as BurlapProxyFactoryBean and BurlapServiceExporter.

        JAX RPC. Spring provides remoting support for Web Services via JAX-RPC.


        • #5
          Note that have dual licenses - GPL (which is viral and forces your code to be also GPL) and a commercial one (not that it's bad or anything - just a heads up).