Am 2017-04-16 um 16:52 schrieb Tibor Digana:
That would still create a string in memory, won't it?
It would still leak in memory while getter is called.
Streaming to XML is better in this case.
Do we have any alternative?
I have to think about it and understand the whole system.
But why not use the regular XMLStreamWriter paired with this:
http://stackoverflow.com/a/20000514/696632.
You'll be able to stream whatever you want.
On Sun, Apr 16, 2017 at 4:40 PM, Michael Osipov <micha...@apache.org> wrote:
Am 2017-04-16 um 16:15 schrieb Tibor Digana:
Since we have XSD [1] we can generate classes and call setters in
particular places in StatelessXmlReporter.java.
Regarding memory consumption system-out may consume really a lot of
memory.
Therefore this is my proposal:
@XmlJavaTypeAdapter(CdataSystemAdapter.class)
public Utf8RecodingDeferredFileOutputStream getSystemOut()
class CdataSystemAdapter
WeakReference with utf8RecodingDeferredFileOutputStream.writeTo(
stream )
return "<![CDATA[" + new String( stream, UTF_8 ) + "]]>"
That would still create a string in memory, won't it?
[1]
https://maven.apache.org/surefire/maven-surefire-plugin/xsd/
surefire-test-report.xsd
This needs a rewrite, too much duplication, no typing but xs:string only.
On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <
ml-node+s40175n5906482...@n5.nabble.com> wrote:
Am 2017-04-16 um 14:21 schrieb Tibor Digana:
Hi,
I want to first talk with you about XML marshaller StatelessXmlReporter
[1]
in Surefire which is built on the top of SharedUtils'
PrettyPrintXMLWriter.
I found out issues after a contributor opened this issue [2].
The problem is that we are using two streams, OutputStream and Writer,
to
create XML in file system for one reason. We write CDATA directly to the
stream apart of xml facility. We have bug with escaping illegal
characters.
Instead, my proposal is to create XSD and Jaxb stubs and marshal it to
XML
file and we do need to care about low level XML and escaping characters.
The code will be easier to understand. The elements system-out and
system-err can be large but we have the stream already in temp files
Utf8RecodingDeferredFileOutputStream which means that the Jaxb
mashaller
will not keep String in memory too long - only while Marshaller needs
the
string.
What is your opinion?
Looking at the current code -- a lot of boilerplate. I am quite
experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].
Consider that JAXB always holds the model in memory. If you intend to
maintain streams within an XML you can resort fragments and other stuff
MOXy supports. But let me tell you that it won't be that easy as you
think if you want everything as streaming with little memory usage.
Michael
BTW: this should go to dev@
[1] https://github.com/highsource/maven-jaxb2-plugin
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5906482&i=0>
For additional commands, e-mail: [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5906482&i=1>
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlRepo
rter-fo-JAXB-
tp5906482.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m
acro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX
BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
.
NAML
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m
acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base
=nabble.naml.namespaces.BasicNamespace-nabble.view.web.
template.NabbleNamespace-nabble.view.web.template.NodeNamesp
ace&breadcrumbs=notify_subscribers%21nabble%3Aemail.
naml-instant_emails%21nabble%3Aemail.naml-send_instant_
email%21nabble%3Aemail.naml>
--
View this message in context: http://maven.40175.n5.nabble.c
om/Re-rewrite-StatelessXmlReporter-fo-JAXB-tp5906482p5906521.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
