Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Spring-WS Security exception handling [SWS-648] #751

Closed
gregturn opened this issue Nov 1, 2010 · 6 comments
Closed

Document Spring-WS Security exception handling [SWS-648] #751

gregturn opened this issue Nov 1, 2010 · 6 comments
Assignees
Milestone

Comments

@gregturn
Copy link
Member

@gregturn gregturn commented Nov 1, 2010

Paul Nyheim opened SWS-648 and commented

In #673, the exceptionHandler property was introduced into the AbstractWSSecurityInterceptor.
This creates an inconsistency with the overall exceptionhandling architecture in Spring WS.

Instead of introducing the EndpointExceptionResolver in this Interceptor, would it not be better to just let the exception flow up to the MessageDispatcher, where the resolvers already are configured (with sensible defaults)

And as this is not documented anywhere unlike the exception resolving in the MessageDispatcher (http://static.springsource.org/spring-ws/sites/1.5/reference/html/server.html#server-endpoint-exception-resolver), it is too easy to miss out on or forget this extra configuration step.

In my opinion this could be done for both the client and endpoint handleRequest/handleResponse methods by just removing the catch clauses.
I would be happy to contribute a patch for this if needed.


Affects: 1.5.7, 2.0 M3

@gregturn
Copy link
Member Author

@gregturn gregturn commented Nov 1, 2010

Arjen Poutsma commented

The problem here is that we'd like any security exception to result in a security-specific SOAP Fault by default. We can't do that in the default configuration of the MessageDispatcher (or exception resolvers), since the specific exceptions (WsSecurityValidationException and WsSecurityFaultException) are part of the spring-ws-security module.

So I agree that this is architecturally inconsistent, but I don't see any nice way out. Also note that we can't break backwards compatibility here.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Nov 1, 2010

Arjen Poutsma commented

Closing as Won't Fix for now.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Nov 1, 2010

Paul Nyheim commented

In that case, I suggest that the documentation around exception handling should be improved.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Nov 1, 2010

Arjen Poutsma commented

Updated issue to reflect documentation is required.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Nov 1, 2010

Arjen Poutsma commented

Agreed, I've reopened the issue (& edited it accordingly).

@gregturn
Copy link
Member Author

@gregturn gregturn commented May 4, 2012

Arjen Poutsma commented

Closing old issues

@gregturn gregturn closed this May 4, 2012
@gregturn gregturn added this to the 1.5.10 milestone Sep 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.