CURRENT RELEASE

THE LATEST RELEASE:

2.0.0 was published on 25.06.2017

DOCUMENTATION OF THE RELEASE:

Read documentation of 2.0.0 release:

IMPORTANT NOTE ON OPENJDK:

with introduction of latest Jetty HTTP server (used by Unity) it was observed that Firefox browser have troubles connecting to Unity launched on some of the OpenJDK distributions (e.g. Fedora). This is due to disabling EC TLS ciphers in affected OpenJDK. In case of troubles please use Oracle Java RE.

GENERAL INFORMATION ABOUT THE RELEASE:

There are two distribution formats:

  • tar.gz bundle which can be unpacked and this way installed in a single directory,
  • rpm which can be installed system-wide in the Linux standard locations.

The rpm is build and tested on Centos 7, noarch. It should work flawlessly also on SL7 and recent Fedora distributions. We may build packages for other distributions in future, however the tar.gz format should be fully portable. Java 8 JRE is the primary installation prerequisite. For more detailed installation information please check the Unity manual.

2.0.X RELEASE SERIES

IMPORTANT: upgrade from 1.9.x to 2.0.0 series is not 100% automated, so please read very carefully the upgrade documentation!

The biggest (by far!) change brought by Unity 2 is the fully rewritten storage layer, which started to be the biggest problem after couple of years of Unity development. Now it is carefully designed and covered by well over 600 tests (and counting), run for all supported storage mechanisms. We have also introduced many improvements in the software architecture and project organization. That change provides a great gain for all of us: we will be able to develop new features more quickly and effectively.

There are also practical implications of the aforementioned refactorings and couple of other notable changes:

  • The storage layer can be changed. If you are interested in development of a storage backend using say Cassandra of MongoDB – feel free to contact us to get some initial support. But we also created a new, alternative storage mechanism on our own and ship it already now. It is based on the in-memory grid technology powered by the excellent Hazelcast stack, which gave name to this storage backend. Hazelcast storage is currently still experimental (and will be so for the next one or two updates of Unity) but you are welcome to give it a test right now. It provides built-in support for HA, clustering and is significantly faster then the traditional RDBMS (MySQL or PostgreSQL) backend. And you can switch between them two back and forth!
  • The stable, traditional RDBMS engine is now significantly faster – this is an effect of our optimizations and cleaner design.
  • We have changed logging subsystem to log4j v2. The very dated log4j v1 had its limitations, the v2 is super-charged with tons of features and is probably the fastest of the mature Java logging implementations around. Speed is always disputable, but finally we shouldn’t have limits in logging output control, rolling, filtering etc.
  • We have added support for customized handling of system events in Unity. This is a super-powerful mechanism, allowing you to enhance Unity behavior to a degree which was not possible before. So far the feature allows for binding Groovy scripts which are invoked in effect of server startup events (replacing the old Java content initializers). You can relatively simply prepare a script that populates Unity database in any way you prefer, including even the most advanced settings. What is more you can add Groovy scripts to be triggered after any operation of Unity platform – to implement custom notifications auditing or custom side-effects inside Unity: you have full access to platform API from script as well as to the original operation invocation context.
  • Local password credential storage was replaced with a more secure one. The one used in Unity 1.9 was configurable and allowed to have even very insecure settings. Now even weakest allowed settings are reasonably secure, and what is more we are prepared for changing key derivation functions in future. Note that by default upgrade won’t force your users to change the password stored using legacy mechanism, and so changing it to be stored using new mechanism. Still we strongly suggest to force the users to do so: there is a new checkbox controlling this behavior in password credential settings.
  • RPM installation integrates now with systemd, the old “init.d” startup scripts were removed.
  • E-mail identities are now NOT treated as case sensitive before @ – as they are in the Unity 1.x.

There is a separate update HOWTO providing detailed instruction on upgrade.

DETAILED LIST OF CHANGES

Bugs fixed:
  • 585 WellKnown links and confirmation endpoints always expose Vaadin debug mode
New features:

 

  • 537 Refactoring of basic types
  • 538 Refactor persistence store to offer a clean API
  • 597 More secure and changable password storage
  • 578 Email identity should be case insensitive before @
  • 574 Implement complete Hazelcast flush tests
  • 573 Consider removing most of the prototype factories for pluggable types
  • 572 move to the latest log4j 2.6
  • 569 Refactor current java initializers into new groovy type initializer
  • 568 Add an option to unityServer.conf for groovy initializer
  • 566 Introduce flexible initializers.
  • 555 Update RPM installation to use systemd
  • 542 Use millisecond precission in MySQL timestamps
  • 516 Remove ‘local’ attribute feature

OLDER REVISIONS

Here you can download previous versions from the series and read their documentation:

There were no older revisions in this series yet.