Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352607

Summary:

Missing information on server exceptions

Product:

z_Archived

Reporter:

Claudio Guglielmo <claudio.guglielmo>

Component:

Scout

Assignee:

Project Inbox <scout.core-inbox>

Status:

CLOSED FIXED

QA Contact:

Severity:

minor

Priority:

CC:

ivan.motsch, stephan.merkli, zimmermann

Version:

3.8.0

Flags:

zimmermann: juno+

Target Milestone:

3.8.1

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Patch	hannes.mueller: iplog+, hannes.mueller: review+

Description Claudio Guglielmo

2011-07-20 11:22:35 EDT

Build Identifier: 3.7.0

If an exception happens on the server it will be replaced with and outline exception which is forwarded to the client. Stacktrace and message gets lost which is fine.

But: The error code and severity of the exception gets lost too. In my opinion it is no security risk to have this information on client side. So please add this information to the outbound exception.

Reproducible: Always

Comment 1 Ivan Motsch

2012-01-24 11:08:53 EST

You can simple create (on server side) a subclass of DefaultTransactionDelegate:

public class MyTransactionDelegate extends DefaultTransactionDelegate{
...
  protected Throwable replaceOutboundException(Throwable t) {
    your code...
  }
}


Then include it in your /process servlet as:

public class MyServiceTunnelServlet extends ServiceTunnelServlet{
...
  protected ServiceTunnelResponse runServerJobTransactionWithDelegate(ServiceTunnelRequest req, Bundle[] loaderBundles, Version requestMinVersion, boolean debug) throws Exception {
    return new MyTransactionDelegate(loaderBundles, requestMinVersion, debug).invoke(req);
  }

}

Comment 2 Claudio Guglielmo

2012-01-30 06:45:55 EST

Hi Ivan

Your right, it easy to exchange the default behaviour which is great!

However, in my opinion the severity is a useful information and no security risk, so why should it be removed as default?

Regards
Claudio

Comment 3 Stephan Merkli

2012-09-13 06:43:42 EDT

*** Bug 389485 has been marked as a duplicate of this bug. ***

Comment 4 Claudio Guglielmo

2012-09-13 06:46:44 EDT

Reopened because still not fixed.

Comment 5 Stephan Merkli

2012-09-13 07:27:04 EDT

Created attachment 221032 [details]
Patch

Patch adds two new constructors to VetoException and makes sure that in DefaultTransactionDelegate, the newly created VetoException has the same error code and severity as the initial one.

Comment 6 Stephan Merkli

2012-09-14 02:22:23 EDT

Due to the two new constructors for VetoException, a object creation by using 
new VetoException("message", null /* cause */, errorCode, IProcessingStatus.ERROR) 
is now ambiguous and 
new VetoException("message", errorCode, IProcessingStatus.ERROR) 
should be used instead.

Comment 7 Stephan Merkli

2012-09-14 02:49:56 EDT

Patch committed.

Comment 8 Matthias Zimmermann

2012-11-13 02:35:47 EST

shipped with scout juno sr1