77 Specially crafted SWA request can take down server with OOM:
fixed in 441cdd3
can set saaj.mime.soapBodyPartSizeLimit system property to the max allowed size of the soapMessagePart to prevent maliciously crafted messages to take down the server with OutOfMemoryError
Parser-pool "leak", discussed in #73 Make EnvelopeFactory ParserPool capacity configurable:
fixed in bcb3cd8
this is a little bit involved, but the essence is that this change ensure that the parser is always returned to the pool which it was taken from. It is not guarantied that when the finally-block called parserPool.get() that it would get the same pool from the ContextClassloaderLocal which the parser was acquired from, because they are cached in a WeakHashMap, which may have been GC-ed between the time the parser was taken, and later returned. The change keeps the reference to the ParserPool in scope to also be used to return the parser. This particular problem with ContextClassloaderLocal is mentioned in https://github.com/eclipse-ee4j/metro-saaj/issues/73#issuecomment-424014253
Re b3bc03e, I am not sure how the glassfish-copyright-maven-plugin works, but it would not let the build pass unless we changed some years in some of the changed files' copyright notices, strangely to 2014, which seems a bit odd. The cherry-picked commits were originally from 2014. Maybe the plugin only regard the latest commit in the commit graph as to resolve which year should be in the copyright notice?
Originally we had to release our own patched version of SAAJ in 2014 to not be affected by this issues in production. To be able to use the latest version of SAAJ we had to include these fixes in a new internal release based on v1.5.1. This has now run in our production environment with a relatively substantial load, and no problems, for about a month. I hope this can be contributed back to the official repository.
This pull-request fixes several issues.
77 Specially crafted SWA request can take down server with OOM:
saaj.mime.soapBodyPartSizeLimitsystem property to the max allowed size of the soapMessagePart to prevent maliciously crafted messages to take down the server withOutOfMemoryErrorParser-pool "leak", discussed in #73 Make EnvelopeFactory ParserPool capacity configurable:
finally-block calledparserPool.get()that it would get the same pool from theContextClassloaderLocalwhich the parser was acquired from, because they are cached in aWeakHashMap, which may have been GC-ed between the time the parser was taken, and later returned. The change keeps the reference to theParserPoolin scope to also be used to return the parser. This particular problem withContextClassloaderLocalis mentioned in https://github.com/eclipse-ee4j/metro-saaj/issues/73#issuecomment-424014253Re b3bc03e, I am not sure how the
glassfish-copyright-maven-pluginworks, but it would not let the build pass unless we changed some years in some of the changed files' copyright notices, strangely to 2014, which seems a bit odd. The cherry-picked commits were originally from 2014. Maybe the plugin only regard the latest commit in the commit graph as to resolve which year should be in the copyright notice?Originally we had to release our own patched version of SAAJ in 2014 to not be affected by this issues in production. To be able to use the latest version of SAAJ we had to include these fixes in a new internal release based on v1.5.1. This has now run in our production environment with a relatively substantial load, and no problems, for about a month. I hope this can be contributed back to the official repository.