This guide covers migrating MDWorkbench Server 2.0 to MDWorkbench Server 2.1.
One of the goals of MDWorkbench Server 2.1 was to move MDWorkbench Server forward while remaining compatible with previous versions to the greatest extent possible. That is, plug-ins written against the MDWorkbench Server 2.0 APIs should continue to work in 2.1 in spite of any API changes.
The key kinds of compatibility are API contract compatibility and binary compatibility. API contract compatibility means that valid use of 2.0 APIs remains valid for 2.1, so there is no need to revisit working code. Binary compatibility means that the API method signatures, etc. did not change in ways that would cause existing compiled ("binary") code to no longer link and run with the new 2.1 libraries.
While every effort was made to avoid breakage, there are a few areas of incompatibility or new APIs that should be adopted by clients. This document describes those areas and provides instructions for migrating 2.0 plug-ins to 2.1.
No known compatibility issue.
Starting with MDWorkbench Server 2.1, web application properties can be configured using Servlet Context Parameters. In previous versions, System properties were mandatory to configure such properties.
Through System properties shall still be used and don't suffer from a compatibility issue, developers are now encouraged to configure MDWorkbench Server using Servlet Context Parameters. Servlet Context Parameters are much more flexible as they can be assigned to a specific web application. They are also easier to configure, some web containers even provide web pages to configure those parameters.
MDWorkbench Server 2.1 introduces the concept of workspace, which is a location in the server file system where the application is free to store data.
Developers are strongly recommended to explicitly configure the workspace location.
If not set, the workspace location defaults to a folder within the directory referenced by the Java "user.home" System property.
Configuring the workspace location is particularly important if the web container runs in a non-interactive mode
(e.g. if the server is started as a Windows Service),
in which case there is no user directory assigned.
With the introduction of the workspace location, all Storage content is now located within the workspace directory.
Developers who configured an explicit storage location using the mdw.server.storage.location property
are now encouraged to remove this setting and let the storage content be stored in the workspace location.
Unless there's good a reason to keep this external storage location set,
it seems more convenient to have all MDWorkbvench Server data being stored in the same place.