Mandiax / soi-toolkit

Automatically exported from code.google.com/p/soi-toolkit
0 stars 0 forks source link

Remove objToStr-transformer for file-based transports #94

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Problem
============
The default generated service for SFTP has a reference to the 
objToStr-transformer which causes the heap to blow up when used with large 
files.

  <sftp:inbound-endpoint
    ...
    transformer-refs="objToStr logMsgIn">
    ...
  </sftp:inbound-endpoint>            

Suggestion
============
Do not generate a ref to objToStr-transformer for file-based transports (file, 
sftp, ftp).

Original issue reported on code.google.com by hakan.d...@callistaenterprise.se on 14 Feb 2011 at 4:13

GoogleCodeExporter commented 8 years ago

Original comment by hakan.d...@gmail.com on 14 Feb 2011 at 4:17

GoogleCodeExporter commented 8 years ago
Issues with charset
====================
Converting to String can easily cause charset conversion problems that are 
non-trivial to understand at first.

Example:
Reading in a file in UTF-8 format and converting to String might work well - 
but if the String isn't explicitly converted to byte[] it will get converted by 
the SFTP-transport in org.mule.transport.sftp.SftpMessageDispatcher like:

} else if (data instanceof String) {
  inputStream = new ByteArrayInputStream(((String) data).getBytes());

i.e. using the platforms default characterset - which might be UTF-8 or 
something else. On Windows it will typically be cp1252 (~ ISO-8859-1) which 
does not work with multibyte characters.

Suggestion
===========
Alt 1. Do not generate a ref to objToStr-transformer for file-based transports 
(file, sftp, ftp) at all.

Alt 2. Instead of the objToStr-transformer, generate a 
objToByteArray-transformer and let any default-generated transformer class 
explicitly handle going from byte[] to String and back to byte[] before handing 
off to the SFTP/FTP/File transport.

Original comment by hakan.d...@gmail.com on 10 Jun 2011 at 12:23

GoogleCodeExporter commented 8 years ago
The generated code has to follow one and the same pattern to keep complexity 
down.
The generated code is based on a String based payload so this is not a very 
good idea.

REgarding the string transformer issues with encoding it should be addressed by 
the project owning each specific transformer and not soi-toolkit. I guess the 
transformers mentioned in the text are standard Mule transformers? 

Original comment by magnus.l...@gmail.com on 17 Jun 2011 at 10:25

GoogleCodeExporter commented 8 years ago
Move to 0.5.1

Original comment by magnus.l...@gmail.com on 30 Nov 2011 at 3:48

GoogleCodeExporter commented 8 years ago
Moved to 0.5.2

Original comment by magnus.l...@gmail.com on 6 Apr 2012 at 7:52

GoogleCodeExporter commented 8 years ago
Moved to 0.5.2

Original comment by magnus.l...@gmail.com on 6 Apr 2012 at 7:53

GoogleCodeExporter commented 8 years ago
Move all v0.5.2 issues to v0.6.2

Original comment by magnus.l...@gmail.com on 26 Jul 2012 at 4:17