Bug 450051

Summary:	Have a headless DialectUIServices.export() which use OutputStream instead if directly create File
Product:	[Modeling] Sirius	Reporter:	Esteban DUGUEPEROUX <esteban.dugueperoux>
Component:	Diagram	Assignee:	Project Inbox <sirius.diagram-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	pierre-charles.david
Version:	1.0.0	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Esteban DUGUEPEROUX

2014-11-05 03:44:43 EST

In our Sirius based application, we want get byte array of diagram export, we use DialectUIManager.INSTANCE.export() to export to a temporary file and read this file to get a byte array.
But it will be more direct to have our byte array.

Comment 1 Pierre-Charles David

2014-11-05 05:00:25 EST

Provide an alternative version of export() which takes an OutputStream instead of an IPath. This way you can provide it a ByteArrayOutputStream if that is really what you want but it is more flexible and does not impose the allocation of potentially huge byte array.

Note that GMF's CopyToImageUtil, which we use for this, is hard-coded to only handle IPath/IFile, even though in the end it calls a saveToOutputStream(), but that method is private. This means copying code from GMF to adapt it (and maybe push a patch to their gerrit/bugzilla to support OutputStream more directly).

The alternative would be to save into a temporary file and then read its content back as a byte array, but this you can already do with the current APIs.

Comment 2 Esteban DUGUEPEROUX

2014-11-05 08:17:01 EST

Yes an OutputStream would be better especially for scalability, i.e. avoid Java heap space with big diagram.
In our Sirius based application in which we use also CDO, we use export to store diagram image byte array in a CDO repo, but we have frequently Java heap space because of big diagram export. Using an OutputStream would solve this issue.

The good solution would be to patch CopyToImageUtil to avoid thisJava heap space.

Comment 3 Pierre-Charles David

2016-04-22 11:16:45 EDT

(In reply to Pierre-Charles David from comment #1)
> Note that GMF's CopyToImageUtil, which we use for this, is hard-coded to
> only handle IPath/IFile, even though in the end it calls a
> saveToOutputStream(), but that method is private. This means copying code
> from GMF to adapt it (and maybe push a patch to their gerrit/bugzilla to
> support OutputStream more directly).

Note that this part may be easier once https://git.eclipse.org/r/#/c/68358/ is merged, as it seems to duplicate the parts of GMF we would need to expose.