handling for java.rmi.UnmarshalException

[tom.elrod]

This thread is related to jira issue JBAS-2999 (http://jira.jboss.com/jira/browse/JBAS-2999).

So I see two issues here (as Adrian stated in the case). The first is how to identify that unmarshalling exception occurred on the server side and convert it proper ejb exception type (java.rmi.UnmarshallException). Where the exception originates (org.jboss.invocation.MarshalledInvocation), the exception thrown is java.lang.IllegalStateException.

Not sure should change the exception type thrown from IllegalStateException, as am not sure which callers are checking for this exception (and certainly don't think it should be changed to any exception type that extends EJBException, since MarshalledInvocation should not be directly tied to ejb). If leave as IllegalStateException, think would need to be caught and converted to UnmarshalException within one of the ejb specific interceptors (like org.jboss.proxy.ClientContainer or org.jboss.proxy.ejb.StatelessSessionInterceptor). However, don't seem to be doing any ejb specific exception conversions in these classes, so don't know if there is a reason for this that I don't know of? Also, don't know if java.lang.IllegalStateException would ever be a valid exception that could be thrown so could not blindly convert it for every instance it is caught in one of these container specific intercepters.

As for the other issue, of the arguments not being referenced (e.g. the security check fails), hell if I know. Assume throwing security exception would supercede the need for throwing an UnmarshalException. Is this not what is required by the spec?

[adrian.brock]

The issue is about compliance, so yes change it.

1) Throw JBossLazyUnmarshallingException extends EJBException
2) In LogInterceptor map it to the spec defined java.rmi.UnmarshalException
(for remote invocations)
(we really need to break the exception mapping into a different interceptor but that is a different issue :-)
3) And most important, write tests - including IIOP

IllegalStateException could come from anywhere.
It needs its own type if you are going to reliably identify it.

Nothing checks for it, it was only introduced in 4.0.3 see the linked case
and that was to fix some **stupid** code.

[tom.elrod]

I thought other technologies besides ejb use MarshalledInvocation? So shouldn't JBossLazyUnmarshallingException just be a custom exception that does *not* extend EJBException?

As for using the LogInterceptor, what if that is removed? Certainly acceptable for user to do this and still make ejb calls. Shouldn't this be put in one of the container specific interceptors?

I *totally* agree with exception specific interceptor.

As for the writing of tests. Is there anyone available to do that? I don't know enough about the IIOP specific one in particular, so would require a good bit of time to do this (and will be after next week at the earliest that I can get to it).

[adrian.brock]

I thought other technologies besides ejb use MarshalledInvocation? So shouldn't JBossLazyUnmarshallingException just be a custom exception that does *not* extend EJBException?

Ok. Just make it a runtime exception, But then it will need to
be mapped to an EJBException for local.
Not that you should get an UnmarshalException for a local invocation. :-)

As for using the LogInterceptor, what if that is removed? Certainly acceptable for user to do this and still make ejb calls. Shouldn't this be put in one of the container specific interceptors?

No the LogInterceptor is the current place for mapping our exceptions
to the spec defined ones.

As for the writing of tests. Is there anyone available to do that? I don't know enough about the IIOP specific one in particular, so would require a good bit of time to do this (and will be after next week at the earliest that I can get to it).

As long at it gets done by 4.0.4.GA
IIOP is not difficult to test.
You just need to copy one of the existing examples and then
not deploy one of the classes that is only used in a parameter.

[tom.elrod]

Ran into a snag using the LogInterceptor. I made the code changes locally and wrote a test case within testsuite for this where pass an argument to the ejb whose type will not be available on the server side (can check all this in now if need to look at it).

Problem is that org.jboss.ejb.Container asks for the invocation object for its arguments before ever getting to the LogInterceptor (thus the JBossLazyUnmarshallingException is thown from that point).

Stack trace is:

org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed
 at org.jboss.invocation.MarshalledInvocation.getArguments(MarshalledInvocation.java:513)
 at org.jboss.ejb.Container.invoke(Container.java:891)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
 at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
 at sun.rmi.transport.Transport$1.run(Transport.java:148)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
 at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
 at java.lang.Thread.run(Thread.java:534)
 at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
 at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
 at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
 at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
 at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:348)
 at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
 at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
 at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
 at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
 at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
 at $Proxy2.testMethod(Unknown Source)
 at org.jboss.test.marshal.test.EjbUnMarshalUnitTestCase.testUnMarshalException(EjbUnMarshalUnitTestCase.java:50)

This is for standard ejb invocation (have not even gotten to iiop invocation yet).

[starksm64]

Container.invoke is either going to have to handle the unmarshall problem while trying to pass the arguments needed for the jacc ejb argument context data, or the EJBArgsPolicyContextHandler needs to take the Invocation and call Invocation.getArguments on demand. I would expect the iiop case to be handled by that layer before ever getting to the Container.invoke, but you might want to create a testcase to be sure before choosing one or the other fix.

[tom.elrod]

Have updated code base so that org.jboss.invocation.MarshalledInvocation will now throw org.jboss.invocation.JBossLazyUnmarshallingException. If org.jboss.ejb.plugins.LogInterceptor or org.jboss.ejb.Container catches this exception, will convert to javax.ejb.EJBException if local and java.rmi.UnmarshalException if not.

This works for the regular (non iiop) test case (see more on that below), but I am not really happy with the changes made as starting to clutter up the interceptors. I would really appreciate someone looking this over in case there is something I missed (jira should contain the file changes for the commit). Right now, is only in 4.0 branch.

Have added org.jboss.test.marshal.test.EjbUnMarshalUnitTestCase to the testsuite for regular ejb invocations and passes. Can run:

jboss-4.0.x\testsuite>ant one-test -Dtest=org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase

Have also added org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase for iiop invocations, but can't get test to run yet. When I run:

jboss-4.0.x\testsuite>ant iiop-test -Dtest=marshaliiop

I always get:

iiop-test:
 [delete] Deleting: C:\Projects\JBoss\JBoss-4_0\jboss-4.0.x\testsuite\output\log\test.log
 [junit] Running org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase
 [junit] java.security.AccessControlException: access denied (java.io.FilePermission C:\Projects
JBoss\JBoss-4_0\jboss-4.0.x\testsuite\junit100927201.properties read)
 [junit] at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269

 [junit] at java.security.AccessController.checkPermission(AccessController.java:401)
 [junit] at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 [junit] at java.lang.SecurityManager.checkRead(SecurityManager.java:863)
 [junit] at java.io.FileInputStream.<init>(FileInputStream.java:100)
 [junit] at java.io.FileInputStream.<init>(FileInputStream.java:66)
 [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunne
.java:514)
 [junit] Exception in thread "main"
 [junit] Test org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase FAILED

Anyone have any ideas? Would also get this error sometimes when running the other iiop tests.

[anil.saldhana]

I saw similar errors on a different testsuite and the issue is mainly due to the security manager enabled while running the testcase.

<!--
 | Run iiop testcases in a single directory by specifing the test
 | directory name in -Dtest=dirname in tests/dirname/test/**TestCase.class
 -->
 <target name="iiop-test" depends="maybejars" if="test"
 description="Execute a single test.">
 <mkdir dir="${build.reports}"/>
 <mkdir dir="${build.testlog}"/>
 <!-- Remove the test.log so each run has a fresh log -->
 <delete file="${build.testlog}/test.log"/>
 <junit dir="${module.output}"
 printsummary="${junit.printsummary}"
 haltonerror="${junit.haltonerror}"
 haltonfailure="${junit.haltonfailure}"
 fork="${junit.fork}"
 timeout="${junit.timeout}"
 jvm="${junit.jvm}">

 <jvmarg value="${junit.jvm.options}"/>
 <sysproperty key="jbosstest.deploy.dir" file="${build.lib}"/>
 <sysproperty key="build.testlog" value="${build.testlog}"/>
 <sysproperty key="log4j.configuration" value="file:${build.resources}/log4j.xml"/>

 <jvmarg value="-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB"/>
 <jvmarg value="-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton"/>
 <jvmarg value="-Djacorb.orb.print_version=off"/>
 <jvmarg value="-Djacorb.log.default.verbosity=0"/>
 <jvmarg value="-Djacorb.interop.strict_check_on_tc_creation=off"/>
 <jvmarg value="-Djacorb.log.loggerFactory=org.jboss.util.Log4jLoggerFactory"/>
 <jvmarg value="-Djacorb.security.ssl.client.supported_options=0"/>
 <jvmarg value="-Djacorb.security.ssl.client.required_options=0"/>
 <jvmarg value="-DORBInitRef.NameService=corbaloc::${node0}:3528/JBoss/Naming/root"/>
 <jvmarg value="-Dorg.omg.PortableInterceptor.ORBInitializerClass.org.jboss.tm.iiop.TxClientInterceptorInitializer"/>
 <jvmarg value="-Djava.security.manager"/>
 <jvmarg value="-Djava.security.policy==${build.resources}/${test}/client.policy"/>

 <sysproperty key="log4j.properties" file="${build.resources}/log4j.properties"/>
 <!-- Pass along any jbosstest.* system properties -->
 <syspropertyset>
 <propertyref prefix="jbosstest."/>
 </syspropertyset>

 <classpath>
 <pathelement location="${build.classes}"/>
 <pathelement location="${build.resources}"/>
 <path refid="tests.classpath"/>
 <path refid="jboss.iiop.classpath"/>
 </classpath>

 <formatter type="xml" usefile="${junit.formatter.usefile}"/>

 <batchtest todir="${build.reports}"
 haltonerror="${junit.batchtest.haltonerror}"
 haltonfailure="${junit.batchtest.haltonfailure}"
 fork="${junit.batchtest.fork}">

 <fileset dir="${build.classes}">
 <include name="org/jboss/test/${test}/**/*TestCase.class"/>
 </fileset>
 </batchtest>
 </junit>
 </target>

Can you see the security manager enabled? Just remove it and see if the testcase works. If not, you need to update the FilePermission in the client.policy file.

[anil.saldhana]

What I mean, is that if you need the security manager to stay enabled (I am guessing it should), then you will need a FilePermission for the junit/ant combo in the client.policy file.

[anil.saldhana]

Tom has confirmed that all is well.

[tom.elrod]

Thanks Anil. Putting in client.policy worked. Am now to the point where getting a usable error. Don't know what to do with it (Francisco, any advice?), but at least a starting point. Error is:

 <testcase classname="org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase" name="testUnMarshalException" time="0.721">
 <error message="java.rmi.RemoteException: CORBA UNKNOWN 0 No; nested exception is:
 org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No" type="java.lang.Exception">java.lang.Exception: java.rmi.RemoteException: CORBA UNKNOWN 0 No; nested exception is:
 org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No
 at org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase.testUnMarshalException(EjbUnMarshalUnitTestCase.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.rmi.RemoteException: CORBA UNKNOWN 0 No; nested exception is:
 org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No
 at com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:134)
 at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
 at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:150)
 at org.jboss.proxy.ejb.DynamicIIOPStub.invokeInt(DynamicIIOPStub.java:244)
 at org.jboss.test.marshaliiop.interfaces._MarshalSession_Stub.testMethod(Unknown Source)
 at org.jboss.test.marshaliiop.test.EjbUnMarshalUnitTestCase.testUnMarshalException(EjbUnMarshalUnitTestCase.java:47)
 ... 21 more
Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException vmcid: 0x0 minor code: 0 completed: No
 at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:180)
 at org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:326)
 at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:963)
 at org.jacorb.orb.Delegate.invoke(Delegate.java:857)
 at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
 at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:125)
 ... 24 more
Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
 at java.lang.Class.getConstructor0(Class.java:1929)
 at java.lang.Class.getConstructor(Class.java:1019)
 at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:167)
 ... 29 more

Guess there needs to be a mapping added in the corba code somewhere. Will try debugging tomorrow.

[tom.elrod]

Thanks to some help from Francisco (thanks btw), both ejb jrmp and ejb iiop tests are passing now in 4.0 branch (will update HEAD shortly).

ant one-test -Dtest=org.jboss.test.marshal.test.EjbUnMarshalUnitTestCase

and

ant iiop-test -Dtest=marshaliiop

see jira issue for further details.

[tom.elrod]

Oh, wanted to mention again, that would really like a review of changes made to org.jboss.ejb.plugins.LogInterceptor and org.jboss.ejb.Container.

Adrian, this is mainly directed to you as don't want to hear 6 months from now how i messed it up and have no memory of the changes I made. ;)

[starksm64]

I looked at the Container changes and seem fine except for the munging of the imports which have been reordered and wildard imports introduced. I restored the previous imports.

[starksm64]

Why isn't the handling of the JBossLazyUnmarshallingException in the LogInterceptor redundant? Wildcard imports have also showed up there. You need to increase your ide settings.