org.eclipse.scout.commons/Release Notes.txt - scout/org.eclipse.scout.rt - Git at Google

 16.08.2010 abr
 merged org.eclipse.scout.nls classes into org.eclipse.scout.commons bundle
 moved public static methods from org.eclipse.scout.nls.NlsPlugin to org.eclipse.scout.nls.sdk.operations.AbstractCreateNlsProjectOperation
 REMOVE dependencies on org.eclipse.scout.nls from MANIFEST.MF, feature.xml and product files
 RENAME import org.eclipse.scout.nls. TO import org.eclipse.scout.commons.nls.

 08.09.20101 imo
 Since slf4j and logback is highly fragmented without any benefit, merged all slf4j and logback to one plugin "ch.qos.logback.all" at
 https://svn.bsiag.com/tools/internal/logback.bsi/trunk/ch.qos.logback.all

 Migration is optional
 1. In the *.product files remove the following plugins
 ch.qos.logback.core
 ch.qos.logback.slf4j
 org.slf4j.api
 org.slf4j.ext
 org.slf4j.jcl
 org.slf4j.jul
 org.slf4j.log4j
 2. Add only the plugin
 ch.qos.logback.all
 3. In the project-specific fragment containing the logback.xml change the bundle-host in the MANIFEST.mf to "ch.qos.logback.all"

 03.11.2010 abr
 Modified MatrixUtility.sort: use NLSLocale instead of the formatting locale (i.e. Locale.getDefault()) for sorting arrays if
 the sort method without a Locale is used: org.eclipse.scout.commons.MatrixUtility.sort(Object[][], int...)
 Migration: none. If really the formatting Locale is required switch to MatrixUtility.sort(Locale.getDefault(), ...)

 16.11.2010 imo
 Since slf4j and logback is sometimes hiding log entries and due to the fact that scout must not support these out of the box,
 reverted basic log handling to only supporting java and eclipse log out of the box.
 Scout therefore supports classic eclipse log (using IStatus) and java log (using java.util.logging.Logger).
 Details can be found in javadoc of org.eclipse.scout.commons.logger.ScoutLogManager

 Migration: It is recommended NOT to use slf4j and logback with eclipse scout projects, it is too complex.
 Remove all "ch.qos.logback*" "org.slf4j*" and log4j plugins from your product configurations and dependencies.
 Remove the project-specific logback fragments from the project.
 When using special logging filters, rollover logs etc. configure this in the standard java logger.properties in the project.
 Details can be found in the google: "java util logger config"
 *** Settings in config.ini for using classic eclipse log, this is normally used only in client appliactions on swt:
 eclipse.consoleLog=true
 org.eclipse.scout.log=eclipse
 org.eclipse.scout.log.level=WARNING

 *** Settings in config.ini for using java standard log, this is the recommended usage:
 eclipse.consoleLog=false
 org.eclipse.scout.log=java

 05.01.2011 imo
 Eliminated javax.mail and javax.jms plugins due to severe issues in sun's handling of javamail and mailcap configuration.
 jax-ws interferes with javamail in a global static way which is dependent on which classloader initiates the factory.
 The result is a lucky guess which class loader context loads the mailcap resources.
 Migration:
 * the endorsed jars are at O:\Scout SDK\Releases\Head\jre-lib-endorsed
 * when using JRE 1.5: copy  javax.mail.jre15_1.4.1.jar and javax.jms_1.1.0.jar to the jre\lib\endorsed folder of the JRE.
 * when using JRE 1.6: copy javax.mail.jre16_1.4.3.jar and javax.jms_1.1.0.jar to the jre\lib\endorsed folder of the JRE.
 * restart eclipse, check installed jre's eventually press the button "Restore Defaults"
 * remove the plugins from the IDE, the trunk IDE is automatically updated
 * remove all import dependencies to javax.jms, javax.mail, javax.activation and com.sun
 * remove all references to javax.mail, javax.activation, javax.jms and com.sun in *.product, *.xml and MANIFEST.MF files
 * for every project using javax.* open project properties:
 Build Path
  Libraries
   JRE System Library
    Access Rule
     Button "Edit..."
      Button "Add"
       add a new entry with "Accessible" javax/**

 27.04.2011 dwi
 Problem:
 There was a need to
  - set dynamically a global log level
  - record log messages
  - add custom log implementations
 Solution:
 - The log level can be set dynamically using IScoutLogManager#setGlobalLogLevel(Integer globalLogLevel)
 - log messages can be recorded by using IScoutLogManager#startRecording() and IScoutLogManager#stopRecording()
 - other logging implementations can be installed by creating a fragment to the host Plug-In 'org.eclipse.scout.commons' with the class 'org.eclipse.scout.commons.logger.CustomLogManager' placed in it.
 Migration: None

 24.05.2011 hmu
 Ticket: 102'394
 Bugzilla  Bug 346619
 Bugzilla  Bug 346190
 Problem: Sending of MimeMessages with LotusNotes failed
 Solution:
 - MailUtility.createMimeMessageFromWordArchiveInternal changed
 - MailUtility.writeHtmlBody added
 - MailUtility.writePlainBody added
 Migration: None

 10.06.2011 imo
 Internal BSI security audit
 The legacy functionality of using &...& sql binds (instead of :abc or #abc#) can lead to sql injection if not used carefully.
 Added warning whenever such code is used.
 Support is eliminated in future release.
 To disable warnings (not recommended) set the server-side config.ini property org.eclipse.scout.commons.sqlplainbind=true
 To enable strict mode (recommended) set the server-side config.ini property org.eclipse.scout.commons.sqlplainbind=false
 Strict mode throws an exception on usages of &..&
 Migration:
 Remove all occurrences and usages of &...& binds.
 Use regex "&[\{\[]*[a-zA-Z]+[a-zA-Z0-9._\[\]\{\}]*&" to find occurrences.
 When statement part composition is really needed, use string concatenation instead.

 04.08.2011 abr
 Bugzilla - Bug: 353924
 DynamicNLS and its extensions can now be used outside a running Eclipse (e.g. in a plain JUnit test).
 Migration: None

 22.08.2011 dwi
 BSI ticket #105'026, #104'976
 Problem:
 - Failed to display corrupt HTML pages (e.g. if missing closing quote in style definition)
 - In HTML editor, no cleanup (auto-correction) should be applied to the given HTML. That is because if the user did some modifications in the HTML source and reloads the HTML in the editor anew, unwanted auto-corrections would be applied.
 Solution:
 - Accomplish consistency concerning HTML styling (cleanup) in between of Swing and SWT in regard of ScoutHtmlField and ScoutHmtEditor.
   In more detail, this entails the following:
   - Before passing the HTML to the respective widget (ScoutHtmlEditor, ScoutHtmlField), Abstract[Swing|Swt]Environment#styleHtmlText() is called to cleanup the given HTML.
   - In case of HTML editor mode, no modifications are applied to the given HTML in both, Swing and SWT, respectively.
   - However, in non-editor mode, some intelligence is applied to the HTML to ensure proper display of the HTML document.
     - In Swing, cleanup of HTML structure and CSS definitions is done. That is crucial as Swing HTML viewer has some problems with some CSS constructs.
     - In SWT, OS default browser is used. That is why cleanup of CSS is not necessary as done by browser itself.
       But, because the HTML is provided as file to the browser, proper encoding and charset must be set.
 - Failsafe: if HTML text cannot be parsed for cleanup, the raw HTML text is used instead of an exception thrown.
 - Consolidation of HTML cleanup functionality in HTMLUtility for plain and simple use that is applicable for both, SWT and Swing, respectively. That is why various methods in HtmlUtility are removed.
 Plug-Ins affected:
 - org.eclipse.scout.commons (HTMLUtility
 - org.eclipse.scout.rt.client (AbstractHtmlField)
 - org.eclipse.scout.rt.ui.swing (AbstractSwingEnvironment, SwingScoutHtmlField, SwingScoutMailField)
 - org.eclipse.scout.rt.ui.swing.bsi.fragment (SwingScoutHtmlEditor)
 - org.eclipse.scout.rt.ui.swt (AbstractSwtEnvironment, SwtScoutHtmlField)
 - org.eclipse.scout.rt.ui.swt.bsi.fragment (SwtScoutHtmlEditor)
 Migration Swing / SWT:
 - In HTMLUtility, the following methods are removed.
   - HTMLUtility#parseDocument(String) to be replaced by HTMLUtility.toHtmlDocument(String)
   - HTMLUtility#formatDocument(String) to be replaced by HTMLUtility.toHtmlText(HTMLDocument)
   - HTMLUtility#cleanupDocument(HTMLDocument, String, int) to be replaced by HTMLUtility.cleanupHtml(String, boolean,boolean, DefaultFont)
   - HTMLUtility#wellformDocument(HTMLDocument, String, int) to be replaced by HTMLUtility.cleanupHtml(String, boolean,boolean, DefaultFont)
 Migration SWT:
 - In AbstractSwtEnvironment, the following methods are removed as not required anymore because logic is encapsulated in HTMLUtility.
   - AbstractSwtEnvironment#styleHtmlText(Control, String)
   - AbstractSwtEnvironment#createCSS(Control)
   - AbstractSwtEnvironment#createHtmlDocument(String, String)

 25.08.2011 dwi
 BSI ticket #105'026
 Problem:
 Default font specific issues in HTML cleanup which is applied to the HTML text prior being provided to AbstractHtmlField:
  - Application specific default font settings should always be applied to body style definition if not specified yet
  - default font size unit on SWT should be pt instead of px
  - precedence of font-families should be supported in default font settings
 Solution:
 - Changed HTMLUtility#cleanupHtml(..) to ensure default font settings to be contained in CSS style definition
 - changed default font size unit in AbstractSwtEnvironment#createDefaultFontSettings(Control) to pt
 Plug-Ins changed:
 - org.eclipse.scout.commons
 - org.eclipse.scout.rt.ui.swt
 - org.eclipse.scout.rt.ui.swing
 - org.eclipse.scout.rt.ui.rap
 Migration:
 None

 30.09.2011 dwi [patch provided by dbu, BSI Business Systems Integration AG]
 BSI ticket #106'584
 Bugzilla 359358
 Problem:
 The HTML created from within a Microsoft Word file contains user-specific, unnecessary information.
 Also, not referenced attachments are included which unnecessarily increase the size of the MIME-message.
 Solution:
 Removed user-specific data and redundant attachments
 Plug-Ins changed:
 - org.eclipse.scout.commons [MailUtility.class]
 Migration:
 None

 18.10.2011 aho
 bugzilla ticket: 361256
 To make reuse of the ServletFilters in RAP projects. The following classes
 should be moved to the 'org.eclipse.scout.http.servletfilter' bundle:
 - org.eclipse.scout.rt.server.servlet.filter.AbstractChainableSecurityFilter
 - org.eclipse.scout.rt.server.servlet.filter.AnonymousSecurityFilter
 - org.eclipse.scout.rt.server.servlet.filter.BasicSecurityFilter
 - org.eclipse.scout.rt.server.servlet.filter.DataSourceSecurityFilter
 - org.eclipse.scout.rt.server.servlet.filter.LDAPSecurityFilter
 - org.eclipse.scout.rt.server.servlet.filter.TomcatSecurityFilter
 All servlet filters in the 'org.eclipse.scout.rt.server' bundle were kept as @deprecated subclasses of the moved ones.
 Furthermore the
 'org.eclipse.scout.rt.shared.services.common.security.SimplePrincipal' should
 be moved to the 'org.eclipse.scout.commons' bundle.
 Migration: change all 'org.eclipse.scout.rt.shared.services.common.security.SimplePrincipal' imports to 'org.eclipse.scout.commons.security.SimplePrincipal'.

 26.10.2011 dwi
 Bugzilla ticket 361795
 Problem:
 Decorating a Date or a Number has to use NlsLocale-Settings.
 Currently, Locale.getLocal() is used which may contradict with user-settings.
 Solution:
 In Java 6 it is possible to contribute custom Locales (e.g. en_CH) to the JRE. That is why Scout NlsLocale is not used anymore and therefore marked as deprecated.
 The user's locale is accessed as follows:
 - On client side, the user's locale is accessed by Locale.getDefault()
 - On server side the request's locale is accessed by LocaleThreadLocal.get() (convenience accessor: ServerSession.get().getLocale())
 Eventhough the class NlsLocale is marked as deprecated for legacy support, its constructor 'NlsLocale(Locale)' was removed because NlsLocale was changed to only act as delegate to the thread's locale (if applicable) or default locale otherwise.
 Please note: A locale consists of its language and country. The country is mainly responsible for format settings as for instance the grouping separator of numbers. A very few locales already exist in the JRE. But if you like to have the application in the English language with Switzerland as its region, you have to contribute your own locale-implementation 'en_CH'. Please see Migration section for detailed instructions to extend JRE with a custom locale.
 Plug-Ins changed:
 - org.eclipse.scout.commons
 - org.eclipse.scout.rt.client
 - org.eclipse.scout.rt.server
 - org.eclipse.scout.rt.shared
 - org.eclipse.scout.rt.ui.swing
 - org.eclipse.scout.rt.oraclelite10g.core
 - org.eclipse.scout.rt.xstream.shared
 Migration:
 - removed NlsLocale(Locale) (constructor): use Locale instead of NlsLocale
 - removed IServerSession#getNlsLocale(): use IServerSession#getLocale() instead (e.g. replace all ServerSession.get().getNlsLocale().getLocale() by ServerSession.get().getLocale())
 - In client Plug-Ins: replace NlsLocale.getDefault().getLocale() by Locale.getDefault()
 - In server Plug-Ins: replace NlsLocale.getThreadDefault().getLocale() by LocaleThreadLocal.get()
 - In shared Plug-Ins: replace NlsLocale.getDefault().getLocale() by NlsUtility.getDefaultLocale()
 Contribution of custom locales to the JRE:
 1. Create a plain Java project, e.g. x.y.localeprovider.en.ch
 2. Create two classes that inherit from {@link DateFormatProvider} and {@link NumberFormatProvider} and implement the method stubs specific to your locale
 3. Create the folder META-INF/services with two files java.text.spi.DateFormatProvider and java.text.spi.NumberFormatProvider
 4. In those files, simply put the the fully qualified name to your date/number provider
 5. Export project as JAR file and put it into \lib\ext of your JRE

 24.11.2011 dwi
 Bugzilla ticket 364545
 BSI ticket 108'224
 Problem:
 In table cells, tabulators are not rendered correctly namely as non-breaking spaces.
 Solution:
 Tabs are only to be interpreted as real tabs in multiline tables. If non-HTML text is content of a cell, its content is encoded to be printed as HTML.
 >In StringUtility#htmlEncode, tabs are to be converted into HTML tabs in the form of <span style=\"white-space:pre\">&#9;</span>
 >In StringUtility#htmlDecode, HTML tabs and HTML breaks are to be converted into \t and \n, respectively.
 Migration:
 None

 24.11.2011 dwi
 Bugzilla ticket 360195
 BSI ticket 105'945
 Problem:
 If creating a MIME-message from within a Word archive, files like item0001.xml und props0002.xml should also be filtered.
 Solution:
 Files with the following names are excluded:
 - filelist.xml
 - colorschememapping.xml
 - themedata.thmx
 - header.html
 - editdata.mso
 - item\\d{4}\\.xml [regex]
 - props\\d{4}\\.xml [regex]
 Migration:
 None

 28.11.2011 dwi
 Bugzilla: 364019
 Problem:
 There has to be a possibility to disable the behaviour of Ctrl+C on tables. A use case for this would be an application
 with sensitive information (e.g. address data) that should not be allowed to be exported, only to be displayed to the user.
 Solution:
 > Added the method 'AbstractTable#execCopy(ITableRow[])' to return a transfer object to be put into the clipboard
 > By default, a TextTransferObject is returned with a text/plain and text/html representation of the selected rows.
   That means that if the target understands HTML, the HTML representation is used over the plain-text representation.
 > In SWT, added copy support on tables (not implemented yet)
 > Added permission 'CopyToClipboardPermission' to enable / disable the copy functionality
 Migration Swing:
 > So far, the copy functionality was enabled by default. Because protected by a permission, it is disabled by default as of now.
   To enable the CTRL-C behavior on tables, add the permission 'CopyToClipboardPermission' to the permission-set in AbstractAccessControlService#execLoadPermissions
   or directly grant it to specific user roles in your database script.
 Migration SWT:
 > None because not supported yet. To enable the copy functionality, see migration notes for Swing.

 29.11.2011 dwi/imo
 Bugzilla: 358369 (bug-fix)
 Problem:
 BeanArrayHolder should implement Serializable to be used as transfer object in client-server communication.
 However, the wrapped type must not necessarily be serializable to also be used as holder for any beans (e.g. beans of a webservice stub)
 Solution:
 Changed BeanArrayHolder to implement Serializable. This only applies to the holder, not the wrapped type.
 Migration: None

 03.01.2012 dwi
 Bugzilla: 367507
 Problem:
 When having a single line textfield (getConfiguredMultilineText=false), leading and trailing newlines should not be replaced by spaces but omitted insted.
 Solution:
 Leading and trailing newlines are trimmed prior to replacing them by spaces.
 Plug-Ins changed:
 org.eclipse.scout.commons [StringUtility], org.eclipse.scout.rt.ui.swing [SwingScoutTextFieldComposite#P_SwingDocumentFilter], org.eclipse.scout.rt.client [SwingScoutTextFieldComposite]
 Migration: None
	16.08.2010 abr
	merged org.eclipse.scout.nls classes into org.eclipse.scout.commons bundle
	moved public static methods from org.eclipse.scout.nls.NlsPlugin to org.eclipse.scout.nls.sdk.operations.AbstractCreateNlsProjectOperation
	REMOVE dependencies on org.eclipse.scout.nls from MANIFEST.MF, feature.xml and product files
	RENAME import org.eclipse.scout.nls. TO import org.eclipse.scout.commons.nls.

	08.09.20101 imo
	Since slf4j and logback is highly fragmented without any benefit, merged all slf4j and logback to one plugin "ch.qos.logback.all" at
	https://svn.bsiag.com/tools/internal/logback.bsi/trunk/ch.qos.logback.all

	Migration is optional
	1. In the *.product files remove the following plugins
	ch.qos.logback.core
	ch.qos.logback.slf4j
	org.slf4j.api
	org.slf4j.ext
	org.slf4j.jcl
	org.slf4j.jul
	org.slf4j.log4j
	2. Add only the plugin
	ch.qos.logback.all
	3. In the project-specific fragment containing the logback.xml change the bundle-host in the MANIFEST.mf to "ch.qos.logback.all"

	03.11.2010 abr
	Modified MatrixUtility.sort: use NLSLocale instead of the formatting locale (i.e. Locale.getDefault()) for sorting arrays if
	the sort method without a Locale is used: org.eclipse.scout.commons.MatrixUtility.sort(Object[][], int...)
	Migration: none. If really the formatting Locale is required switch to MatrixUtility.sort(Locale.getDefault(), ...)

	16.11.2010 imo
	Since slf4j and logback is sometimes hiding log entries and due to the fact that scout must not support these out of the box,
	reverted basic log handling to only supporting java and eclipse log out of the box.
	Scout therefore supports classic eclipse log (using IStatus) and java log (using java.util.logging.Logger).
	Details can be found in javadoc of org.eclipse.scout.commons.logger.ScoutLogManager

	Migration: It is recommended NOT to use slf4j and logback with eclipse scout projects, it is too complex.
	Remove all "ch.qos.logback" "org.slf4j" and log4j plugins from your product configurations and dependencies.
	Remove the project-specific logback fragments from the project.
	When using special logging filters, rollover logs etc. configure this in the standard java logger.properties in the project.
	Details can be found in the google: "java util logger config"
	*** Settings in config.ini for using classic eclipse log, this is normally used only in client appliactions on swt:
	eclipse.consoleLog=true
	org.eclipse.scout.log=eclipse
	org.eclipse.scout.log.level=WARNING

	*** Settings in config.ini for using java standard log, this is the recommended usage:
	eclipse.consoleLog=false
	org.eclipse.scout.log=java

	05.01.2011 imo
	Eliminated javax.mail and javax.jms plugins due to severe issues in sun's handling of javamail and mailcap configuration.
	jax-ws interferes with javamail in a global static way which is dependent on which classloader initiates the factory.
	The result is a lucky guess which class loader context loads the mailcap resources.
	Migration:
	* the endorsed jars are at O:\Scout SDK\Releases\Head\jre-lib-endorsed
	* when using JRE 1.5: copy javax.mail.jre15_1.4.1.jar and javax.jms_1.1.0.jar to the jre\lib\endorsed folder of the JRE.
	* when using JRE 1.6: copy javax.mail.jre16_1.4.3.jar and javax.jms_1.1.0.jar to the jre\lib\endorsed folder of the JRE.
	* restart eclipse, check installed jre's eventually press the button "Restore Defaults"
	* remove the plugins from the IDE, the trunk IDE is automatically updated
	* remove all import dependencies to javax.jms, javax.mail, javax.activation and com.sun
	* remove all references to javax.mail, javax.activation, javax.jms and com.sun in .product, .xml and MANIFEST.MF files
	* for every project using javax.* open project properties:
	Build Path
	Libraries
	JRE System Library
	Access Rule
	Button "Edit..."
	Button "Add"
	add a new entry with "Accessible" javax/**

	27.04.2011 dwi
	Problem:
	There was a need to
	- set dynamically a global log level
	- record log messages
	- add custom log implementations
	Solution:
	- The log level can be set dynamically using IScoutLogManager#setGlobalLogLevel(Integer globalLogLevel)
	- log messages can be recorded by using IScoutLogManager#startRecording() and IScoutLogManager#stopRecording()
	- other logging implementations can be installed by creating a fragment to the host Plug-In 'org.eclipse.scout.commons' with the class 'org.eclipse.scout.commons.logger.CustomLogManager' placed in it.
	Migration: None

	24.05.2011 hmu
	Ticket: 102'394
	Bugzilla Bug 346619
	Bugzilla Bug 346190
	Problem: Sending of MimeMessages with LotusNotes failed
	Solution:
	- MailUtility.createMimeMessageFromWordArchiveInternal changed
	- MailUtility.writeHtmlBody added
	- MailUtility.writePlainBody added
	Migration: None

	10.06.2011 imo
	Internal BSI security audit
	The legacy functionality of using &...& sql binds (instead of :abc or #abc#) can lead to sql injection if not used carefully.
	Added warning whenever such code is used.
	Support is eliminated in future release.
	To disable warnings (not recommended) set the server-side config.ini property org.eclipse.scout.commons.sqlplainbind=true
	To enable strict mode (recommended) set the server-side config.ini property org.eclipse.scout.commons.sqlplainbind=false
	Strict mode throws an exception on usages of &..&
	Migration:
	Remove all occurrences and usages of &...& binds.
	Use regex "&[\{\[][a-zA-Z]+[a-zA-Z0-9._\[\]\{\}]&" to find occurrences.
	When statement part composition is really needed, use string concatenation instead.

	04.08.2011 abr
	Bugzilla - Bug: 353924
	DynamicNLS and its extensions can now be used outside a running Eclipse (e.g. in a plain JUnit test).
	Migration: None

	22.08.2011 dwi
	BSI ticket #105'026, #104'976
	Problem:
	- Failed to display corrupt HTML pages (e.g. if missing closing quote in style definition)
	- In HTML editor, no cleanup (auto-correction) should be applied to the given HTML. That is because if the user did some modifications in the HTML source and reloads the HTML in the editor anew, unwanted auto-corrections would be applied.
	Solution:
	- Accomplish consistency concerning HTML styling (cleanup) in between of Swing and SWT in regard of ScoutHtmlField and ScoutHmtEditor.
	In more detail, this entails the following:
	- Before passing the HTML to the respective widget (ScoutHtmlEditor, ScoutHtmlField), Abstract[Swing\|Swt]Environment#styleHtmlText() is called to cleanup the given HTML.
	- In case of HTML editor mode, no modifications are applied to the given HTML in both, Swing and SWT, respectively.
	- However, in non-editor mode, some intelligence is applied to the HTML to ensure proper display of the HTML document.
	- In Swing, cleanup of HTML structure and CSS definitions is done. That is crucial as Swing HTML viewer has some problems with some CSS constructs.
	- In SWT, OS default browser is used. That is why cleanup of CSS is not necessary as done by browser itself.
	But, because the HTML is provided as file to the browser, proper encoding and charset must be set.
	- Failsafe: if HTML text cannot be parsed for cleanup, the raw HTML text is used instead of an exception thrown.
	- Consolidation of HTML cleanup functionality in HTMLUtility for plain and simple use that is applicable for both, SWT and Swing, respectively. That is why various methods in HtmlUtility are removed.
	Plug-Ins affected:
	- org.eclipse.scout.commons (HTMLUtility
	- org.eclipse.scout.rt.client (AbstractHtmlField)
	- org.eclipse.scout.rt.ui.swing (AbstractSwingEnvironment, SwingScoutHtmlField, SwingScoutMailField)
	- org.eclipse.scout.rt.ui.swing.bsi.fragment (SwingScoutHtmlEditor)
	- org.eclipse.scout.rt.ui.swt (AbstractSwtEnvironment, SwtScoutHtmlField)
	- org.eclipse.scout.rt.ui.swt.bsi.fragment (SwtScoutHtmlEditor)
	Migration Swing / SWT:
	- In HTMLUtility, the following methods are removed.
	- HTMLUtility#parseDocument(String) to be replaced by HTMLUtility.toHtmlDocument(String)
	- HTMLUtility#formatDocument(String) to be replaced by HTMLUtility.toHtmlText(HTMLDocument)
	- HTMLUtility#cleanupDocument(HTMLDocument, String, int) to be replaced by HTMLUtility.cleanupHtml(String, boolean,boolean, DefaultFont)
	- HTMLUtility#wellformDocument(HTMLDocument, String, int) to be replaced by HTMLUtility.cleanupHtml(String, boolean,boolean, DefaultFont)
	Migration SWT:
	- In AbstractSwtEnvironment, the following methods are removed as not required anymore because logic is encapsulated in HTMLUtility.
	- AbstractSwtEnvironment#styleHtmlText(Control, String)
	- AbstractSwtEnvironment#createCSS(Control)
	- AbstractSwtEnvironment#createHtmlDocument(String, String)

	25.08.2011 dwi
	BSI ticket #105'026
	Problem:
	Default font specific issues in HTML cleanup which is applied to the HTML text prior being provided to AbstractHtmlField:
	- Application specific default font settings should always be applied to body style definition if not specified yet
	- default font size unit on SWT should be pt instead of px
	- precedence of font-families should be supported in default font settings
	Solution:
	- Changed HTMLUtility#cleanupHtml(..) to ensure default font settings to be contained in CSS style definition
	- changed default font size unit in AbstractSwtEnvironment#createDefaultFontSettings(Control) to pt
	Plug-Ins changed:
	- org.eclipse.scout.commons
	- org.eclipse.scout.rt.ui.swt
	- org.eclipse.scout.rt.ui.swing
	- org.eclipse.scout.rt.ui.rap
	Migration:
	None

	30.09.2011 dwi [patch provided by dbu, BSI Business Systems Integration AG]
	BSI ticket #106'584
	Bugzilla 359358
	Problem:
	The HTML created from within a Microsoft Word file contains user-specific, unnecessary information.
	Also, not referenced attachments are included which unnecessarily increase the size of the MIME-message.
	Solution:
	Removed user-specific data and redundant attachments
	Plug-Ins changed:
	- org.eclipse.scout.commons [MailUtility.class]
	Migration:
	None

	18.10.2011 aho
	bugzilla ticket: 361256
	To make reuse of the ServletFilters in RAP projects. The following classes
	should be moved to the 'org.eclipse.scout.http.servletfilter' bundle:
	- org.eclipse.scout.rt.server.servlet.filter.AbstractChainableSecurityFilter
	- org.eclipse.scout.rt.server.servlet.filter.AnonymousSecurityFilter
	- org.eclipse.scout.rt.server.servlet.filter.BasicSecurityFilter
	- org.eclipse.scout.rt.server.servlet.filter.DataSourceSecurityFilter
	- org.eclipse.scout.rt.server.servlet.filter.LDAPSecurityFilter
	- org.eclipse.scout.rt.server.servlet.filter.TomcatSecurityFilter
	All servlet filters in the 'org.eclipse.scout.rt.server' bundle were kept as @deprecated subclasses of the moved ones.
	Furthermore the
	'org.eclipse.scout.rt.shared.services.common.security.SimplePrincipal' should
	be moved to the 'org.eclipse.scout.commons' bundle.
	Migration: change all 'org.eclipse.scout.rt.shared.services.common.security.SimplePrincipal' imports to 'org.eclipse.scout.commons.security.SimplePrincipal'.

	26.10.2011 dwi
	Bugzilla ticket 361795
	Problem:
	Decorating a Date or a Number has to use NlsLocale-Settings.
	Currently, Locale.getLocal() is used which may contradict with user-settings.
	Solution:
	In Java 6 it is possible to contribute custom Locales (e.g. en_CH) to the JRE. That is why Scout NlsLocale is not used anymore and therefore marked as deprecated.
	The user's locale is accessed as follows:
	- On client side, the user's locale is accessed by Locale.getDefault()
	- On server side the request's locale is accessed by LocaleThreadLocal.get() (convenience accessor: ServerSession.get().getLocale())
	Eventhough the class NlsLocale is marked as deprecated for legacy support, its constructor 'NlsLocale(Locale)' was removed because NlsLocale was changed to only act as delegate to the thread's locale (if applicable) or default locale otherwise.
	Please note: A locale consists of its language and country. The country is mainly responsible for format settings as for instance the grouping separator of numbers. A very few locales already exist in the JRE. But if you like to have the application in the English language with Switzerland as its region, you have to contribute your own locale-implementation 'en_CH'. Please see Migration section for detailed instructions to extend JRE with a custom locale.
	Plug-Ins changed:
	- org.eclipse.scout.commons
	- org.eclipse.scout.rt.client
	- org.eclipse.scout.rt.server
	- org.eclipse.scout.rt.shared
	- org.eclipse.scout.rt.ui.swing
	- org.eclipse.scout.rt.oraclelite10g.core
	- org.eclipse.scout.rt.xstream.shared
	Migration:
	- removed NlsLocale(Locale) (constructor): use Locale instead of NlsLocale
	- removed IServerSession#getNlsLocale(): use IServerSession#getLocale() instead (e.g. replace all ServerSession.get().getNlsLocale().getLocale() by ServerSession.get().getLocale())
	- In client Plug-Ins: replace NlsLocale.getDefault().getLocale() by Locale.getDefault()
	- In server Plug-Ins: replace NlsLocale.getThreadDefault().getLocale() by LocaleThreadLocal.get()
	- In shared Plug-Ins: replace NlsLocale.getDefault().getLocale() by NlsUtility.getDefaultLocale()
	Contribution of custom locales to the JRE:
	1. Create a plain Java project, e.g. x.y.localeprovider.en.ch
	2. Create two classes that inherit from {@link DateFormatProvider} and {@link NumberFormatProvider} and implement the method stubs specific to your locale
	3. Create the folder META-INF/services with two files java.text.spi.DateFormatProvider and java.text.spi.NumberFormatProvider
	4. In those files, simply put the the fully qualified name to your date/number provider
	5. Export project as JAR file and put it into \lib\ext of your JRE

	24.11.2011 dwi
	Bugzilla ticket 364545
	BSI ticket 108'224
	Problem:
	In table cells, tabulators are not rendered correctly namely as non-breaking spaces.
	Solution:
	Tabs are only to be interpreted as real tabs in multiline tables. If non-HTML text is content of a cell, its content is encoded to be printed as HTML.
	>In StringUtility#htmlEncode, tabs are to be converted into HTML tabs in the form of <span style=\"white-space:pre\"> </span>
	>In StringUtility#htmlDecode, HTML tabs and HTML breaks are to be converted into \t and \n, respectively.
	Migration:
	None

	24.11.2011 dwi
	Bugzilla ticket 360195
	BSI ticket 105'945
	Problem:
	If creating a MIME-message from within a Word archive, files like item0001.xml und props0002.xml should also be filtered.
	Solution:
	Files with the following names are excluded:
	- filelist.xml
	- colorschememapping.xml
	- themedata.thmx
	- header.html
	- editdata.mso
	- item\\d{4}\\.xml [regex]
	- props\\d{4}\\.xml [regex]
	Migration:
	None

	28.11.2011 dwi
	Bugzilla: 364019
	Problem:
	There has to be a possibility to disable the behaviour of Ctrl+C on tables. A use case for this would be an application
	with sensitive information (e.g. address data) that should not be allowed to be exported, only to be displayed to the user.
	Solution:
	> Added the method 'AbstractTable#execCopy(ITableRow[])' to return a transfer object to be put into the clipboard
	> By default, a TextTransferObject is returned with a text/plain and text/html representation of the selected rows.
	That means that if the target understands HTML, the HTML representation is used over the plain-text representation.
	> In SWT, added copy support on tables (not implemented yet)
	> Added permission 'CopyToClipboardPermission' to enable / disable the copy functionality
	Migration Swing:
	> So far, the copy functionality was enabled by default. Because protected by a permission, it is disabled by default as of now.
	To enable the CTRL-C behavior on tables, add the permission 'CopyToClipboardPermission' to the permission-set in AbstractAccessControlService#execLoadPermissions
	or directly grant it to specific user roles in your database script.
	Migration SWT:
	> None because not supported yet. To enable the copy functionality, see migration notes for Swing.

	29.11.2011 dwi/imo
	Bugzilla: 358369 (bug-fix)
	Problem:
	BeanArrayHolder should implement Serializable to be used as transfer object in client-server communication.
	However, the wrapped type must not necessarily be serializable to also be used as holder for any beans (e.g. beans of a webservice stub)
	Solution:
	Changed BeanArrayHolder to implement Serializable. This only applies to the holder, not the wrapped type.
	Migration: None

	03.01.2012 dwi
	Bugzilla: 367507
	Problem:
	When having a single line textfield (getConfiguredMultilineText=false), leading and trailing newlines should not be replaced by spaces but omitted insted.
	Solution:
	Leading and trailing newlines are trimmed prior to replacing them by spaces.
	Plug-Ins changed:
	org.eclipse.scout.commons [StringUtility], org.eclipse.scout.rt.ui.swing [SwingScoutTextFieldComposite#P_SwingDocumentFilter], org.eclipse.scout.rt.client [SwingScoutTextFieldComposite]
	Migration: None