Announcement Announcement Module
No announcement yet.
ERROR: RmiInvocationWrapper_Stub (no security manager: RMI class loader disabled) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ERROR: RmiInvocationWrapper_Stub (no security manager: RMI class loader disabled)

    I am trying to use Spring's remoting feature in my application. I have followed the spring accountService example but I am getting the following exception when i try to load the bean from my application code.

    Unable to return specified BeanFactory instance: factory key [], from group with resource name [classpath:beanRefFactory.xml]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '' defined in class path resource [beanRefFactory.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class []: Constructor threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.remoting.rmi.RmiServiceExporter' defined in class path resource [LBSConfig/spring/remoting-service.xml]: Invocation of init method failed; nested exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
    	java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
    	java.lang.ClassNotFoundException: org.springframework.remoting.rmi.RmiInvocationWrapper_Stub (no security manager: RMI class loader disabled)

    THe JAR file containing RmiInvocationWrapper_Stub (springremoting.jar) is present in the classpath.
    Am I missing something.
    here is my Code:

    HTML Code:
    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "spring-beans.dtd">
    	<bean id="beanLocator" class="org.oclc.lbs.infra.framework.spring.BeanLocator">
    	<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
    	<!-- does not necessarily have to be the same name as the bean to be exported -->
    	<property name="serviceName" value="BeanLocator"/>
    	<property name="service" ref="beanLocator"/>
    	<property name="serviceInterface" value="org.oclc.lbs.infra.framework.spring.IBeanLocator"/>
    	<!-- defaults to 1099 -->
    	<property name="registryPort" value="1999"/>

    Java classes:

    package org.oclc.lbs.infra.framework.spring;
     * @author kumara
    public class BeanLocator implements IBeanLocator{
        public BeanLocator()
        public Object getServiceBean(String serviceName, String serviceType)
    I am deploying my application on EAServer and I am trying to instantiate the bean factory by calling the following code from my test Servlet. (Its just a testing i dont care how dirty it is at the moment..)

    Object serviceProvider = null;
            BeanFactoryLocator bfLocator = SingletonBeanFactoryLocator.getInstance("classpath:beanRefFactory.xml");
            BeanFactoryReference bfReference = bfLocator.useBeanFactory("");
            factory = bfReference.getFactory();
            serviceProvider = factory.getBean("sessionManagerService");
    Please help as I am struck with it for quite some time now. Is there any other way that I can expose my business service to my java client in an easy way? Any example would be greatly appreciated. Thanks.

  • #2
    Show content of your beanRefFactory.xml file.


    • #3
      Here are the contents of my beanRefFactory.xml:

      HTML Code:
      <beans default-lazy-init="true">
      	<bean id="" class="" lazy-init="true">        


      • #4
        Config seems ok to me. I tried to reproduce the problem - everything works fine. If you create a complete small test case that reproduces the problem and post it here, I take a look.


        • #5
          Hi dennis,
          Sure I will try to create a small sample app with Spring RMI but as of now I have solved my problem using the Hessian support provided by spring. One thing that I would like to know is when to use HTTP based remoting like Hessain/Burlap and when to use RMI style?
          Which one is better? RMI Style or HTTP Style?
          When to use HTTP Invoker functionality provided by spring to bridge the gap between RMI and Hessian style remoting?
          I understand that RMI uses java's standard serialization mechanism and Hessian/Burlap has their own object serialization mechanism. So which one should we choose if both our client and server components would be deployed 1) on the same server and 2) on different servers.

          Why is it considered difficult to use RMI across firewalls?

          I know a these are a lot of questions, but they popped up while I was reading the remoting functionality provided by Spring?


          • #6
            Why is it considered difficult to use RMI across firewalls?
            Ever tried to convince a security officier/manager to open an port (1099) on the firewall. They normally turn pale, then red in anger and ask you why on earth you would open up such an ridicules port and open up the company to a new security hole.

            Also as 1099 is the default there sometimes is another port involved in communicating with RMI, which in the end leads to not opening 1 port on the firewall but generally a range of ports.

            With HTTP based solutions they don't see that issue as those solutions use the standard port 80.

            When to use which is it depends.

            If you are in control and it is internal and you have a webserver/servlet container and spring use HttpInvoker it uses standard java serialization. If you don't have http use RMI. If you use spring but your clients don't use spring use Hessian/Burlap those 2 protocols are implemented in a whole bunch of languages (C, C#, Perl, etc).

            And as a last resort you can always use CORBA....

            If you want really loose coupling and make your clients independent from your servers implementation (or you have frequent changing clients) you are probably better of with a Document Driver approach, better known as Web Services.


            • #7
              Hi Martin,
              Thanks for the reply. I have a fair amount of idea now and I think I can build up my understanding further based on the facts provided.