EDC logs 404 errors in logs

[florianrusch-zf]

Describe the bug

Every time an endpoint is been request, where the EDC doesn't serve anything he is logging jakarta.ws.rs.NotFoundException to his logs, which could be very spamy and should be avoided. Basically all 2** and 4** http errors are normally not necessary to be logged at all.

Logging config is the one which is configured on default in the helm chart.

To Reproduce

Steps to reproduce the behavior:

1. Call any none existing path
2. See exception in log

Expected behavior

All 2** and 4** http errors shouldn't be visible in the normal logs (but maybe it make sense to log them if debug logs are activated).

[ndr-brt]

out of curiosity, what caused that 404?

[florianrusch-zf]

out of curiosity, what caused that 404?

I am trying to set up EDC 0.7.0 for the first time. It has been started, but for whatever reason I can't reach any of the endpoints I know of (I just get 404s and something like Object of type Asset with ID=request was not found). I'm currently debugging into it to see what I'm doing wrong. I guess it's an OSI layer 8 problem 😉

EDIT: As told, layer 8 problem..../v3/assets/request needs to be called as POST and not GET 🙈

[github-actions]

This issue is stale because it has been open for 4 weeks with no activity.

[github-actions]

This issue is stale because it has been open for 4 weeks with no activity.

[bmg13]

hey @florianrusch-zf can you help me here, please, I have two questions.
The only 4XX I can replicate similar to this is the 405 (method not allowed) when calling incorrect verb (as you mentioned in your last comment).
Regarding the NOT FOUND the stack trace is not generated and the message you presented ("Object of type Asset with ID=test-asset-s4 was not found") is returned, as expected. But, again, I cannot see the 404 stack trace you showed.

So, my questions are:

• How did you replicated the 404 stack trace?
• Shouldn't the 405 be kept as a full exception print? I know it is a 4XX and could be not needed to have all the info dump, but is expected behaviour since this error should never happen with correct API usage.

Proposed technical solution:
If it really is to be fixed, I Believe that in here https://github.com/eclipse-edc/Connector/blob/main/extensions/common/http/jersey-core/src/main/java/org/eclipse/edc/web/jersey/mapper/UnexpectedExceptionMapper.java#L47 the log would include only the message and not the full stack trace, something like
monitor.severe("JerseyExtension: Unexpected exception caught. " + exception.getMessage());

However this would affect any error status case, I believe. @ndr-brt Can you give your input here as well, please?
thank you both 🙇

[ndr-brt]

@bmg13 I definitely think this is something to bring upstream