On Windows Server with Glassfish 4.0 and JDK 1.7_55 I getting NoClassDefFoundError and ClassNotFoundException then invoking remote bean methods.
StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
java.lang.ClassNotFoundException: com.sun.corba.ee.impl.orb.ORBSingleton
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
...
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at dudge.ifaces.__SolutionRemote_Remote_DynamicStub.getSolutionEager(dudge/ifaces/__SolutionRemote_Remote_DynamicStub.java)
at dudge.ifaces._SolutionRemote_Wrapper.getSolutionEager(dudge/ifaces/_SolutionRemote_Wrapper.java)
at dudge.DudgeBean.submitSolution(DudgeBean.java:119)
...
There DudgeBean and SolutionRemote are my classes.
And
StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
java.lang.NoClassDefFoundError: Could not initialize class com.sun.corba.ee.impl.io.IIOPInputStream
at com.sun.corba.ee.impl.io.ValueHandlerImpl.createInputStream(ValueHandlerImpl.java:820)
...
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at dudge.__PermissionCheckerRemote_Remote_DynamicStub.canGetUser(dudge/__PermissionCheckerRemote_Remote_DynamicStub.java)
at dudge._PermissionCheckerRemote_Wrapper.canGetUser(dudge/_PermissionCheckerRemote_Wrapper.java)
at dudge.web.actions.UsersAction.view(UsersAction.java:95)
...
There UsersActionand and PermissionCheckerRemote are my classes.
On development system everything works fine and I can't find a difference. What could be causing this?
It seems that this is a bug related to JDK 1.7_55. After downgrading to JDK 1.7_51 problem was solved.
There is an entry in the Glassfish bug tracker on this bug. https://java.net/jira/browse/GLASSFISH-21047
as @Aleksandr said, this is 7u55's bug.
You can try running glassfish with
JAVA_HOME=/usr/lib/jvm/java-6-oracle ~/glassfish-3/glassfish/bin/asadmin start-domain domain1
This will temporary change JAVA_HOME path. Later you have to check localhost:4848 > srever > JVM report whether java root has changed. If it did not then you probably need to modify asadmin.conf script or domain.xml.
Yes this is a bug. I solved the same problem by upgradin JDK to 1.8.0_25
来源：https://stackoverflow.com/questions/23291520/exception-inside-corba-when-accessing-a-remote-bean