[
https://issues.apache.org/jira/browse/WSCOMMONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved WSCOMMONS-248.
--------------------------------------
Resolution: Fixed
Committed 575430
> Attachment class shouldn't cache soap part in file
> --------------------------------------------------
>
> Key: WSCOMMONS-248
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-248
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Michal Stochmialek
> Assignee: Rich Scheuerle
>
> Since the caching strategy (to cache in file or not) is based on
> content-length of whole mime message,
> all attachments are stored in files no matter if they're small or big. This
> also includes soap part, which
> is usually small comparing to other attachments.
> I believe that it would be difficult to get content length from every mime
> part, since the Content-Length
> is rarely provided. Although IMHO it would be wise to not cache soap part by
> default.
> The patch for Attachments.getPart method could look like this:
> if (fileCacheEnable) {
> try {
> if (contentLength != 0 &&
> - contentLength <= fileStorageThreshold) {
> + contentLength <= fileStorageThreshold
> + || partIndex == 0) {
> // Since the content-length is less than the
> threshold, we can safely
> - // store it in memory.
> + // store it in memory. Other option: part is a soap
> part.
> if (log.isDebugEnabled()) {
> log.debug("Creating an Attachment Part (in
> memory)");
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
