Exception wrapped in java.lang.reflect.UndeclaredThrowableException?

[Graham Withey]

Hi,

I have a method/service on an interface like

public Foo doSomething(Bar bar) throws FooException, RemoteException

In my service implementation if I throw foo exception the calling client receives

java.lang.reflect.UndeclaredThrowableException
which contains a java.lang.reflect.InvocationTargetException
which finally contains my FooException.

What am I doing wrong?

Thanks very much,
Graham

[Dennis Reedy]

Hi Graham,

I dont think you're doing anything wrong. Underneath the covers there is a dynamic proxy created that performs the remote invocation. Thats where the InvocationTargetException comes from. Can you send the stacktrace?

Thanks

Dennis

[Graham Withey]

Hi Dennis,

Here is the stack trace.  Thanks very much for the assistance on this.

java.lang.reflect.UndeclaredThrowableException
    at $Proxy89.getApproverHierchy(Unknown Source)
    at com.travellinck.clients.com.oldmutual.integration.approval.evaluators.Evaluators.getNextEvaluator(Evaluators.java:296)
    at com.travellinck.clients.com.oldmutual.integration.approval.evaluators.Evaluators.determineNextEvaluator(Evaluators.java:174)
    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:597)
    at com.travellinck.infrastructure.jini.space.component.conduit.impl.SimpleEntryBivalve$1.call(SimpleEntryBivalve.java:93)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.reflect.InvocationTargetException
    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:597)
    at org.rioproject.associations.AssociationProxySupport.doInvokeService(AssociationProxySupport.java:198)
    at org.rioproject.associations.AssociationProxySupport$AssociationInvocationHandler.invoke(AssociationProxySupport.java:300)
    ... 13 more
Caused by: com.oldmutual.integration.approval.hierarchy.soap.NoSuchStaffMember:
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
    at $Proxy79.getApproverHierchy(Unknown Source)
    at com.travellinck.components.clients.com.oldmutual.oracle.proxy.approval.ApprovalHierarchiesProxy.getApproverHierchy(ApprovalHierarchiesProxy.java:78)
    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:597)
    at org.rioproject.bean.proxy.BeanDelegator.invoke(BeanDelegator.java:124)
    at $Proxy40.getApproverHierchy(Unknown Source)
    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:597)
    at net.jini.jeri.BasicInvocationDispatcher.invoke(BasicInvocationDispatcher.java:1126)
    at net.jini.jeri.BasicInvocationDispatcher.dispatch(BasicInvocationDispatcher.java:608)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$6.run(ObjectTable.java:597)
    at net.jini.export.ServerContext.doWithServerContext(ServerContext.java:103)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch0(ObjectTable.java:595)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$Target.access$700(ObjectTable.java:212)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$5.run(ObjectTable.java:568)
    at com.sun.jini.start.AggregatePolicyProvider$6.run(AggregatePolicyProvider.java:527)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(ObjectTable.java:565)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(ObjectTable.java:540)
    at com.sun.jini.jeri.internal.runtime.ObjectTable$RD.dispatch(ObjectTable.java:778)
    at net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(ServerConnectionManager.java:148)
    at com.sun.jini.jeri.internal.mux.MuxServer$2.run(MuxServer.java:244)
    at com.sun.jini.start.AggregatePolicyProvider$5.run(AggregatePolicyProvider.java:513)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.jini.jeri.internal.mux.MuxServer$1.run(MuxServer.java:241)
    at com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:136)
    at java.lang.Thread.run(Thread.java:680)
    at com.sun.jini.jeri.internal.runtime.Util.__________EXCEPTION_RECEIVED_FROM_SERVER__________(Util.java:108)
    at com.sun.jini.jeri.internal.runtime.Util.exceptionReceivedFromServer(Util.java:101)
    at net.jini.jeri.BasicInvocationHandler.unmarshalThrow(BasicInvocationHandler.java:1303)
    at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:832)
    at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659)
    at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
    at $Proxy100.getApproverHierchy(Unknown Source)
    ... 19 more

[Dennis Reedy]

Graham,

So whats happening here is nothing you have done, but its due to the way the associations work in Rio. All injected associations are actually dynamic proxys. The association framework in Rio uses this approach in order to provide a service selection strategy for a managed collection of discovered services. The service selection strategy provides a way to determine how services in the collection of discovered services are invoked (see http://www.rio-project.org/associations.html#Service_Selection_Strategies)

By the looks of your stacktrace you seem to be using Rio 4.2. In your exception handling code you would have to check if the exception is an instance of InvocationTargetException and check that the cause is not null. Then you can get your exception (I have changed this in Rio 5.0 to just propagate your exception).

The other thing you can do is not use the injected proxy, and get the "real" proxy. To do that look here: http://www.rio-project.org/associations.html#Association_Injection

HTH

Dennis

[Graham Withey]

Hi Dennis,

Thanks for the reply.

I am running a pretty recent build from source of RIO 5.0 branch could this be a bug?

Thanks
Graham

[Dennis Reedy]

Graham,

Its not a bug, it just the way dynamic proxies work. The cause of the thrown exception is your com.oldmutual.integration.approval.hierarchy.soap.NoSuchStaffMember. 

HTH

Dennis

[Dawid Loubser]

Hi Dan,

If I understand you correctly, you're saying that declared (checked) exceptions will always be wrapped in a java.lang.reflect.UndeclaredThrowableException if the service is invoked via a Rio Proxy?

That's a pity - if true, it would make it impossible to write one's code as pure JavaBeans (agnostic of the infrastructure within which it lives). Is this something we could try and fix (I'm happy to give it a go), or is there an inherent reason for this?

My current understanding, is that service invocation occurs in org.rioproject.associations.AssociationProxySupport#doInvokeService - where you use reflection to invoke the underlying method (on the Jini proxy, most likely). 

In line 206, where the caught exception (which will always be an InvocationTargetException) is re-thrown, we could probably simply unwrap it to expose the underlying exception?

I don't know where the second level of wrapping could be originating from (the java.lang.reflect.UndeclaredThrowableException) because in Graham's example, it appears to be a declared exception.

regards,

Dawid

[Dennis Reedy]

On Jul 5, 2012, at 545AM, Dawid Loubser wrote:

Hi Dan,

If I understand you correctly, you're saying that declared (checked) exceptions will always be wrapped in a java.lang.reflect.UndeclaredThrowableException if the service is invoked via a Rio Proxy?

Seems that they would be wrapped in an InvocationTargetException, not sure why they would be wrapped in an UndelcaredThrowableException

That's a pity - if true, it would make it impossible to write one's code as pure JavaBeans (agnostic of the infrastructure within which it lives). Is this something we could try and fix (I'm happy to give it a go), or is there an inherent reason for this?

My current understanding, is that service invocation occurs in org.rioproject.associations.AssociationProxySupport#doInvokeService - where you use reflection to invoke the underlying method (on the Jini proxy, most likely). 

In line 206, where the caught exception (which will always be an InvocationTargetException) is re-thrown, we could probably simply unwrap it to expose the underlying exception?

Thats what being done now, its queued up on my machine, I'm doing testing with the latest Drools version, so it has not been pushed.

Dennis

[Dawid Loubser]

Thanks for the clarification Dennis - 

We follow a rather formal design-by-contract methodology, so correct exception handling is absolutely paramount to our work. As it stands, we have behaviour failing at runtime which is proven to work correct (via unit testing) at development time because of these unexpected wrapped exceptions.

Any idea how long till you push this particular commit? If it's more than a couple of days, I'll patch it locally until then.

cheerio,

Dawid

[Graham Withey]

Hi Dennis,

Your latest commit has resolved this issue.  Thanks very much.

Graham

[Patel kashi nath]

Hi Dennis,

      I'm getting this can you please help,

java.lang.reflect.UndeclaredThrowableException

at com.sun.proxy.$Proxy0.getSessionLocaleForUser(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.detica.tig.util.LoggingHandler.invoke(LoggingHandler.java:159)

at com.sun.proxy.$Proxy1.getSessionLocaleForUser(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.detica.tig.util.TimeoutHandler$Invocation.run(TimeoutHandler.java:112)

at java.lang.Thread.run(Unknown Source)

regards

Patel.

[Dennis Reedy]

Patel,

Providing additional context would certainly help with any diagnosis. Do you have the complete stacktrace? What are you trying to accomplish? What version of Java, Rio are you using? 

Dennis

--
You received this message because you are subscribed to the Google Groups "Rio Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rio-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.