[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jaxme-dev
Subject:    [jira] [Resolved] (AXIOM-404) Add a feature to detach a builder from the underlying stream
From:       "Andreas Veithen (JIRA)" <jira () apache ! org>
Date:       2015-05-23 20:53:17
Message-ID: JIRA.12534652.1323606130000.17954.1432414397318 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/AXIOM-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Andreas Veithen resolved AXIOM-404.
-----------------------------------
    Resolution: Fixed

> Add a feature to detach a builder from the underlying stream
> ------------------------------------------------------------
> 
> Key: AXIOM-404
> URL: https://issues.apache.org/jira/browse/AXIOM-404
> Project: Axiom
> Issue Type: New Feature
> Components: API
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
> Priority: Minor
> Fix For: 1.2.15
> 
> 
> Because Axiom supports deferred parsing, the input stream from which an object \
> model builder is constructed can only be closed after processing the XML document \
> or message. However, this is not always possible or desirable. Various strategies \
> are used to release the input stream before the document or message is completely \
> processed: 1. The application code can call build() or buildWithAttachments() \
> before closing the stream. This ensures that the object model is entirely built so \
> that the stream is no longer necessary. 2. The application code can read the stream \
> into a ByteArrayOutputStream and then pass a ByteArrayInputStream to Axiom. The \
> garbage collector will take care of releasing the resources linked to the \
> ByteArrayInputStream and the original stream can be released early. 3. Some code in \
> Axis2 (in particular code related to JAX-WS) uses DetachableInputStream: the \
> original stream is wrapped with a DetachableInputStream before being passed to \
> Axiom. If the original stream needs to be closed, DetachableInputStream#detach() is \
> called to buffer the remaining content in memory. 4. For XOP/MTOM messages, the \
> application code could simply instruct Axiom to fetch all MIME parts before closing \
> the stream. This would work because Axiom buffers MIME parts (in memory or in \
> temporary files, depending on the configuration), but this approach appears to be \
> rarely used. None of these strategies is optimal:
> * Strategy 1 implies that the object model is always built completely, even in \
> cases where this is not necessary. buildWithAttachments also requires iterating \
> over the entire message. However, for XOP/MTOM messages this strategy is better \
>                 than 2 and 3 (because it is closer to 4).
> * Strategy 2 is suboptimal because the entire content of the stream needs to be \
> read before starting to process the message. This contrasts with the other \
>                 strategies which can be executed just before the stream is closed.
> * Strategies 2 and 3 add significant overhead for XOP/MTOM messages because the \
>                 content of the message is buffered twice.
> * Strategy 4 is optimal for XOP/MTOM but doesn't apply to plain XML or SOAP \
> messages. Therefore a new feature should be added to the object model builders that \
> allows application code to instruct Axiom to detach the builder from the underlying \
> stream. Axiom would then use the optimal strategy for the given type of builder, \
> i.e. strategy 3 for plain XML or SOAP messages and strategy 4 for XOP/MTOM \
> messages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]