Update Notes

Update Guidance

The update guidance refers always to the current 3.x.x version.

Skipping Versions: Skipping a major Sophora release is not possible any more. Before you install Sophora in version 3 you had to run the Server with a 2.5 version.

How to update your nodes to Sophora 3

Sophora 3 comes with some migrations that need to be performed (Details are explained below). To make these migrations work smoothly, you need to update your Sophora Sophora Replica Servers (including Sophora Delivery Servers) first.

You don't have to update all your Sophora Replica Servers at once, but don't update your Sophora Primary Server unless all your Sophora Replica Servers are running with 3. We propose to switch off your Sophora Primary Server once all Sophora Replica Servers are updated and then make one of your Sophora Replica Servers the new Sophora Primary Server. The former Sophora Primary Server can be started as a Sophora Replica Server then.

The update process of one server takes about 30 - 90 minutes depending on the size of the repository. Please make sure that you run a version later than 2.5.38 before the update. Generally it is recommended to always update from the latest 2.5.x release to the latest 3.x.x version to benefit from the latest improvements and bugfixes regarding the update.
Specifically if the 2.5.x server version you are starting from is 2.5.53 or newer, then make sure to update to server version at least 3.7.7.

[2021-02-17 08:17:52,689, ERROR] [main ] [c.s.sophora.eclipse.util.ErrorUtils : 79] showing error dialog to user:
field type not supported:
Strukturknoten für neue Dokumente (UUID_REFERENCE, com.subshell.sophora.eclipse.structureNodeDocumentFormInputField)
java.lang.UnsupportedOperationException: field type not supported:
Strukturknoten für neue Dokumente (UUID_REFERENCE, com.subshell.sophora.eclipse.structureNodeDocumentFormInputField)

Please make sure that the read-anywhere cluster feature is not activated, when you run Sophora server in different versions in one Sophora cluster. Furthermore, when using a Sophora Server version 3.2.1 and above, make sure that all your tools use at least client version 3.1.0; otherwise inconsistent data may be returned by clients when using the read-anywhere feature.

Unification of Structure Nodes and Structure Node Documents

In Sophora versions prior to 3 structure nodes were defined by two different entities.
The first one was the structure node as a stand-alone API object with predefined properties and the other one an extendable structure node document which was automatically created and linked to the structure node. From version 3 on these two entities are merged into a single structure node document. This merge simplifies the processing of structure nodes and unifies them technically with Sophora documents. As a result, all functionalities that were previously reserved for documents are now also available for structure nodes. Structure nodes are now versioned like documents, and concurrent editing of a structure node by different users is prevented. Structure node permissions can now be defined more granularly.

The new Document Type sophora-nt:structureNode2

Structure nodes are now represented by the primary type sophora-nt:structureNode2. Due to restrictions from the underlying persistence technology JCR it was not possible to reuse the primary type sophora-nt:structureNode. Any project specific mixins that were previously configured on structure node documents are migrated to the new primary type.

Migration

When the Sophora Server is started for the first time with version 3 the structure nodes are automatically migrated to the new data structure. All references to the old structure nodes and structure node documents are preserved.

Since repositories and configurations are widely different, the duration of the migration is hard to predict. We highly suggest to first try this on a test environment that is similar to your production environment.

API

The API has been kept compatible with 2.5.x to the greatest possible extent. Smaller adaptions might be necessary. The class StructureNodeVersion for example has been removed. The functionality can now be achieved by using the class DocumentVersion instead.

There is no need to adopt anything in a web project using the Sophora Delivery. The primary types sophora-nt:structureNodeDocument and sophora-nt:structureNode2 are used synonymously in the configuration file templates.xml. If queries are used that contain the primary type sophora-nt:structureNodeDocument or sophora-nt:structureNode, they must be adopted to use the primary type sophora-nt:structureNode2.
A change to a structure node now always causes a StructureNodeChangedEvent and a DocumentChangedEvent.

Deactivation of Structure Nodes

When a structure node is deactivated this very structure node and all documents recursively located in it are deleted on Sophora Delivery Servers.

In Sophora versions prior to 3 it was not possible to edit documents being located in a deactivated structure node. This has been changed with 3. Deactivation is now achieved by setting the corresponding structure node offline.

Import and Export

Prior to Sophora 3 structure nodes were defined by a structure node XML element and a structure node document XML element in their import and export format.
Both are still supported when importing but the export XML will only contain the XML node for the structure node document.

Image Variants

Image variants can be activated (or be set to related) per site. Prior to Sophora 3 this was part of the configuration of the site object.

This is now changed. The activation per site is part of the configuration of the image variant.

Existing assignments and activations are migrated automatically when a Sophora Server with an existing repository is started for the first time with Sophora 3.

The order of image variants per site can be controlled by the new select value document "Image Variants" (UUID de17d26c-04c0-3d58-860d-ca4a0eb4bda7) that is generated and filled automatically during the migration.

Structure Node Input Fields Consolidated

The input field types

• 'Structure node document (multi)' (com.subshell.sophora.eclipse.multiStructureNodeDocumentFormInputField)
• 'Website (multi)' (com.subshell.sophora.eclipse.siteCheckBox)
• 'Structure node document' (com.subshell.sophora.eclipse.structureNodeDocumentFormInputField)

Use

• 'Structure node' (com.subshell.sophora.eclipse.structureNodeFormInputField) for single properties
• 'Structure node (multi)' (com.subshell.sophora.eclipse.multiStructureNodeFormInputField) for properties with multiple values

An automatic update will perform the conversion to the new input field types on server startup for existing property configurations in your repository.

If you have referenced one of the removed input field types in your code (or node type configurations in your source code management) you will have to adapt those.

Please make sure that you do not import node type configurations containing one of the removed input field types.

Configuration Hashes for Structure nodes unified

The data measured for configuration hashes has been consolidated due to the unification of structure nodes and structure node objects. Therefore you might see configuration differences in your dashboard between slaves and Sophora Primary Server during the migration. They will go away after all your nodes are updated.

Sophora Importer

With Importer version 3.1.0 and newer we also changed the signature of the following methods/constructors:

• com.subshell.sophora.importer.core.creators.ChildNodeSetzer#ChildNodeSetzer
• com.subshell.sophora.importer.core.creators.DocumentCreator#createDocument
• com.subshell.sophora.importer.core.creators.ImportPerRmi#doImport
• com.subshell.sophora.importer.core.creators.ResourceListDocumentsCreator#ResourceListDocumentsCreator
• com.subshell.sophora.importer.core.instructions.AbstractInstructionHandler#AbstractInstructionHandler
• com.subshell.sophora.importer.core.instructions.InstructionProcessor#processInstructions
• com.subshell.sophora.importer.core.instructions.ProposalsCreator#ProposalsCreator
• com.subshell.sophora.importer.core.instructions.StickyNotesHandler#StickyNotesHandler
• com.subshell.sophora.importer.core.instructions.lifecycle.LifecycleManager#LifecycleManager
• com.subshell.sophora.importer.core.job.ImportJob#ImportJob
• com.subshell.sophora.importer.feeds.model.FeedItemImporter#processXml
• com.subshell.sophora.importer.job.FileImportJob#FileImportJob
• com.subshell.sophora.importer.ws.impl.ImportService#importXml

Proposals

Beginning with this version, proposals will internally be stored as Sophora documents of type sophora-nt:proposal. Proposal sections will be stored as entries of a select value document. All proposals will be located under the new structure node "/system/proposals". Permissions for the new document type as well as for the new strucure node will be transparently provided to all roles.

If the Sophora Primary Server is started for the first time in version 3, existing proposals and proposal sections will be migrated to the new format. If the repository contains a considerable number of active proposals, the migration might take a noticeable amount of time (possibly a couple of minutes, depending on the system's configuration).

Since the upgrade scenario involves upgrading the Replication Server before the Sophora Primary Server, the Replication Server will request synchronization of all proposals from the Sophora Primary Server when it is started for the first time in version 3. It is crucial to wait until the synchronization has finished before the Sophora Primary Server is stopped. Otherwise proposals might get lost irrecoverably.

Once all Sophora Primary Servers and Sophora Replica Servers have been upgraded to version 3, the servers might show a different "creation date"-property of the "/system/proposals" structure node document and the proposal sections select value document. These differences will not affect the server's functionality but if the differences persist, they can be resolved by re-saving and/or re-publishing the affected document on the Sophora Primary Server.

Scripting

Support for the script language BeanShell has ceased. All custom scripts should be migrated to Groovy before updating to Sophora 3.

Spring version update

All Sophora components beginning from version 3 use Spring 5. The Spring Boot and Spring Data versions have been updated to version 2. As Spring 5 comes with certain changes, this could have implications on custom implementations as well.

Sophora Server: Hessian API removed

The Hessian API is removed in Server 3. For easy HTTP access to the data, the Content API should be used instead.

Sophora Delivery

AbstractContentMap: Improved Getters

The AbstractContentMap can now parse Long, Double, Date and Boolean values from String properties.

The getBoolean method will no longer throw ClassCastExceptions and instead behaves as getLong, getDouble and getDate do.

More exact invalidation when changing YellowData

The Sophora Delivery used to treat YellowData changes like document changes when it comes to flushing cached content. This has been adjusted with Sophora Delivery 3. Now while creating cacheable fragments the delivery tracks, whether yellow data has been accessed (e.g. through virtual properties) and then flushes cached content accordingly.

To do so, an update has to be performed on the cache DB. This update might take a couple of minutes during the first start after the update. Updating a sample cache DB with 15 million entries took 5 minutes.

New methods in IContentProvider

In Sophora Delivery 3 there are three more methods declared in the interface IContentProvider. If you have an own implementation of IContentProvider you have to implement these methods.

The methods are:

com.subshell.sophora.delivery.api.IContentProvider#checkStartEndDate(com.subshell.sophora.api.content.INode, boolean)
com.subshell.sophora.delivery.api.IContentProvider#checkIsOnline(com.subshell.sophora.api.content.INode, boolean)
com.subshell.sophora.delivery.api.IContentProvider#checkIsNotDeleted(com.subshell.sophora.api.content.INode, boolean)

Changed behaviour when accessing structure nodes without index documents

With Delivery versions 2.5.41, 3.0.2, 4.0 and newer we changed the behaviour when requesting URLs pointing at index documents of structure nodes.

The new behaviour results in the regular handling of missing documents for this structure node.

If you don't want this then you can keep the former behaviour by adding this line to your webapp's sophora.properties:

sophora.delivery.legacyMissingIndexDocumentHandling=true

Textlinks are now XML encoded

Since 3.0.24: Link URLs in <a>-tags generated from link documents (textlinks) are now XML-encoded. (e.g. '&amp;' instead of '&'). If you have encoded them by yourself so far, you should not anymore because this will break your textlink destination because URLs would be encoded twice.

Sophora-Addon Maps

Changed ExtendedData

The Maps addon has been completly rewritten. As a result of that, the stored KML-format has been slightly changed. The initial view earlier has been based on the zoom factor and the view's top left and bottom right corner. However, since the aspect ratio of a browser is not fixed, this has been changed. The view is now based on the zoom factor and the center. For downwards compatibility, the extended data attributes topLeftLat, topLeftLon, bottomRightLat and bottomRightLon have been kept but now refer to the center of the view. For a more explicit handling, the data attributes centerLat and centerLon have been added.

Refinement of the add-on key

With the new Maps addon you can configure the map to be rendered by one of three different providers: Bing, Mapbox and OpenStreetMap. You need to confirm the update "Sophora Maps: Add-on activation refinement" on the first connection with the DeskClient, so that the former add-on key will be changed to the Bing license key. Please note that the keys of Mapbox and OpenStreetMap will not be entered automatically. If you have acquired one of these licenses, it is important to inform your subshell contact to provide these keys to you.

Sophora Client and API

StringKeyLockManager deprecated

The class com.subshell.sophora.commons.locking.StringKeyLockManager is no longer recommended and will be removed in Sophora 5.0.0. Please use com.subshell.sophora.commons.locking.ReentrantLockProvider instead.

DeskClient

New JxBrowser Integration Requires JavaFX

With Version 3 we integrated the Chromium-based JxBrowser into the Sophora DeskClient. DeskClient versions 3.0 to 3.6 and versions 4.0 to 4.2 use JavaFX for this integration and therefore these DeskClient versions require a Java Runtime Environment with included JavaFX. If JavaFX is not available the DeskClient falls back to the SWT browser (the previous default). With DeskClient 3.7 and 4.3 the JxBrowser is still integrated but JavaFX is no longer needed.

Java 8:

• Oracle JRE 8 contains JavaFX, so you have nothing to change.
• OpenJDK 8: Azul ZuluFX and BellSoft Liberica JDK contain JavaFX, AdoptOpenJDK not yet (as of 2019-05-24).

• Oracle JDK 11 and Oracle OpenJDK 11 do not include JavaFX 11, but you can create a custom JRE for each of your OS by using jlink (see below and section "Custom JDK+JavaFX image" from this JavaFX page). At least the following modules are required: java.se, javafx.controls, javafx.swing, jdk.charsets, jdk.crypto.ec jdk.httpserver, jdk.jdi, jdk.localedata, jdk.management.agent, jdk.unsupported, jdk.xml.dom,.
• Other OpenJDKs: Azul ZuluFX and BellSoft Liberica JDK contain JavaFX 11, AdoptOpenJDK not yet (as of 2019-05-24).

On request we deliver the DeskClient also with integrated JRE which includes JavaFX already.

Here is an example batch to create a custom Oracle JRE 11 with JavaFX 11. Note that you must have the JavaFX jmods downloaded for your OS.

set PATH_TO_FX_MODS="C:\Program Files\Java\javafx-jmods-11.0.1"
set JAVA_HOME="C:\Program Files\Java\jdk-11.0.1"
set OUTPUT_DIRECTORY="C:\jdkfx-11.0.1"
%JAVA_HOME%\bin\jlink --module-path %PATH_TO_FX_MODS% --add-modules java.se,javafx.controls,javafx.swing,jdk.httpserver,jdk.jdi,jdk.unsupported,jdk.xml.dom,jdk.management.agent,jdk.localedata,jdk.charsets,jdk.crypto.ec --include-locales en,de --output %OUTPUT_DIRECTORY%

Important Notes for DeskClient 3.4.0 and newer

• The support for 32-bit platforms has been discontinued. The DeskClient only runs on 64-bit platforms and JVMs.
• The DeskClient can no longer be run on Linux with GTK2. Furthermore the SWT_GTK3 environment variable is ignored, as only GTK3 is supported now. Please also note, that GTK versions older than 3.20 are no longer supported.
• Custom DeskClient Plug-ins: You need to declare the javax.inject dependency directly in your MANIFEST.MF file now.
• When updating via update site from an older DeskClient version to version 3.4.0/4.0.0 the automatic restart may fail with an error message. The DeskClient can then be restarted manually. We recommend to roll out the new version without update site for a clean installation.

Important Notes for DeskClient 3.8.0 and newer

• New system requirements: The DeskClient requires Java 11 from version 3.8.0 and no longer starts with Java 8. Please check your custom DeskClient Plug-ins. DeskClients with integrated JRE already use Java 11.
• For updates via update site, an installed DeskClient version 3.7.0 (or newer) is also required so that the automatic restart works without errors.
• Updates to version 4 must be made at least to version 4.4.0.

Default paragraph style in copytext fields

With DeskClient versions 2.5.57, 3.0.9 and 4.0.0 the default paragraph style for copytext fields is not selected from all available styles anymore, but from the list of allowed paragraph styles configured in the property. If there is no paragraph style with display style "default" among them, the alphabetically first of the allowed styles will be used. Copytext fields without any allowed paragraph styles are not valid and will result in errors when creating new documents.

Update by Update Site checks MD5 and SHA

When updating the DeskClient by the update site mechanism the downloaded artifacts are verified by their MD5 and SHA-256 hashes. The update aborts if this check fails.

EPG

Similar to the gap color between two broadcasts in the EPG view the conflict color that is used to show that two broadcasts overlap each other can be configured now. Therefore the nodetype update "EPG: Conflict Colors" is required. The DeskClient will ask you to perform this update if you login as administrator and open the EPG view. Afterwards each station document (sophora-epg-nt:station) has a new field to configure the conflict color.

Teletext

Legacy Teletext features removed

The legacy slot range editor and Texas editor for teletext pages have been completely removed from the DeskClient.

Since Teletext 3.1.1 the technical documentation is available on the Website.

No special Solr core for Teletext required

Since Teletext 3.1.0: The teletext generator requires no special Solr cores to be present and uses internal cores default and default-live existing in Sophora configuration by default.
The Solr core Teletext_Live is not used anymore.

Updated SFTP client

With version 3.2.0 of the Teletext Generator, the outdated ssh-rsa will not be supported anymore by default. You will either need to update your server (SFTP target) to support ssh-rsa2 or add the following Java options to your .conf file to re-enable ssh-rsa:
"-Djsch.server_host_key=...,ssh-rsa -Djsch.client_pubkey=...,ssh-rsa"

Open document by URL in clipboard

The function to open a document via its URL now uses the client/server method to get the UUID of a document via its URL instead of querying the IdForUrlServlet of the previews directly by iterating over the preview URLs of the published preview documents. Therefore, the deliveries must be accessible from the server. Otherwise the server can not ask the deliveries for the UUID.

Custom DeskClient-Plug-ins

API

IEditorComponent

If you have a custom editor for a child node, you have to adapt to the following changes.

In IExtendedEditorPart and IEditorComponent the type ISophoraDocument is now used instead of INode.

• adoptChanges(INode) -> adoptChanges(ISophoraDocument)
• refresh(INode) -> refresh(ISophoraDocument)

If your editor component extends AbstractEditorComponent you have to implement the new method getEditorComponentId(). The returned value must be the fully qualified id of the extension. It consists of the id of your plug-in plus the id of the extension. Your plug-in id is the Bundle-SymbolicName of the MANIFEST.MF. You can find the extension id in the plugin.xml behind the corresponding <extension id=. For the example plugin we added the following, because the plug-in id is already contained in a constant:

@Override
	protected String getEditorComponentId() {
		return Activator.PLUGIN_ID + ".personEditorComponent"; //$NON-NLS-1$
	}

The method IEditorComponent.init() got an additional parameter of type ISelectionProvider. It provides the current selected component and allows to change that selection. All selection changes to components are now only done through this provider. The document editor no longer listens for selection changes to adapt the component selection. To apply this change to your plugin, you just have to provide the new parameter to the super call to AbstractEditorComponent.init(). If you wish to synchronize on the component selection use AbstractEditorComponent.getComponentSelectionProvider().

IFormField

If you have a custom input field for a property, you have to adapt to the following changes.

If your form input field extends AbstractFormField you have to implement the new method getFormInputFieldId(). The returned value must be the fully qualified id of the extension. It consists of the id of your plug-in plus the id of the extension. Your plug-in id is the Bundle-SymbolicName of the MANIFEST.MF. You can find the extension id in the plugin.xml behind the corresponding <extension id=. For the example plugin we added the following, because the plug-in id is already contained in a constant:

@Override
	protected String getFormInputFieldId() {
		return Activator.PLUGIN_ID + ".personFormField"; //$NON-NLS-1$
	}

Furthermore we changed the handling of default values for input field type parameters. For each parameter a default can be provided in the extension (plugin.xml). When accessing the configured parameter of an input field, a default value could be provided. This duplication is now removed and instead of providing a default in the code the default of the extension is used. Therefore the following methods of AbstractFormField changed, by removing the second parameter:

• getIntFromParameters(String, int)
• getDoubleFromParameters(String, double)
• getIntegersFromParameters(String, int)

The method signature of AbstractFormField.getBooleanFromParameters(String) has not changed, but it now also uses the default value of the extension if no value is configured for the parameter. Additionally we added the method getStringFromParameters(String), to retrieve the configured or default value of a field parameter.

You also have to adapt to the following changes.

Additional Changes

Custom Views

The Views menu now only shows Sophora views, i.e. views from a certain category. If your part descriptor has been built using Eclipse 3, the category must be set to "com.subshell.sophora.eclipse" (or "Sophora" if using Eclipse 4) so that the custom view will be displayed in the Views menu.

Dependencies

The DeskClient does no longer reexport the bundle org.eclipse.core.runtime, due to version problems with the (re-)exported package javax.annotation. That bundle is required if you have an activator or use localization (class NLS) and it also provides packages like org.osgi.framework. You should check that your plug-in compiles against the new version of the DeskClient. If some classes from the packages org.eclipse.core.runtime, org.eclipse.osgi or org.osgi are missing, you have to add the dependency directly to your MANIFEST.MF.

Require-Bundle: org.eclipse.core.runtime;bundle-version="3.13.0"

Also the library Guava must now be imported directly to not enforce a version for all plug-ins. Previously this was provided by com.subshell.sophora.eclipse.libs for all plug-ins. Now each plug-in which makes use of Guava has to declare this dependency on its own.

Require-Bundle: com.google.guava;bundle-version="21.0.0"

Since Deskclient 3.4.0 you need to declare the javax.inject dependency directly in your MANIFEST.MF.

Text (Fixed Size): New parameter for changeable background color

The new configuration option "background color changeable" in the input field type "Text field (Fixed Size)" comes with an additional parameter in the com.subshell.sophora.hyphenation.TextDocument constructor. If you wish to use this feature, the constructor with the additional parameter backgroundColor must be used in all scripts that modify the relevant text fields. Otherwise, the changed background color is not persistent. The constructor without a backgroundColor is still valid for text fields that don't implement this feature.

TextDocument(Scale scale, List<String> textLines, List<ManualHyphenation> manualHyphenations, List<TextColor> textColors, 
Optional<RGBColor> backgroundColor)

UGC

Note for the update on 3.1.0: Configuration changes, extension of mixins and a change in the behaviour of the manipulation protection

Since forms and quizzes now also offer protection against manipulation in addition to the votings, there are changes to the configuration of UGC. The configuration of the properties from which the configuration for the manipulation protection was moved from the "voting" configuration to a separate point "manipulation", which applies to all three document types. Accordingly, the mixins for forms and quizzes have been extended by the corresponding properties and should be adjusted during the update. Furthermore, new contributions that are considered manipulation attempts are no longer stored in the database but discarded. When updating UGC, the taglib and the submitter should be updated as before.

Jolokia port

Since 2.5.11 the ugc-webapp opens port 1694 for management including jolokia. If it is already binded by another application you can configure it with management.server.port in application.yml.

Changed UGC Group IDs and Packages

All UGC maven modules changed their groupId from com.subshell.sophora to com.subshell.sophora.ugc. Update your dependencies accordingly. You may also have to change other configurations, e.g. logback.xml, because also the Java package names changed from com.subshell.sophora.usercontent to com.subshell.sophora.ugc.

Due to changed package names, an old (i.e., < 2.5.24) ugc-webapp is not compatible with a new (i.e., >= 2.5.24, >= 3.0.0) ugc-submitter or ugc-taglib. When upgrading UGC from a version < 2.5.24 to 3.x, you should first upgrade the ugc-webapp to at least version 2.5.25 (or 3.0) before increasing the versions of the rest. To prevent that an old version of the taglib is still used, the TLD cache of the tomcat should be deleted during the update. The cache can be found at tomcat/work/Catalina/localhost/{webapp}/org/apache/jsp.

Changed startup of UGC

With UGC release 3.0.0 the UGC webapp has been converted to a standard executable jar that can easily be integrated as a service. Therefore the jar file itself is executable and the script ugc-webapp.sh does not exist anymore.

Changed configuration format

With UGC release 3.0.0 the configuration format of UGC has been changed from JSON to YAML. With all releases following release 3.0.0 UGC is configured in the file application.yml instead of ugc-webapp.json. The existing ugc-webapp.json can be used as template. The file has to be converted to a proper YAML file by removing curly brackets and trailing commas. There are a few small changes to the existing properties like the usage of standard server.port property instead of jetty.httpPort and all parameter group names on top level have to be converted from camel case to dash-case properties.

Rest Endpoints

With release 3.0.10 for all rest endpoints wich are using an externalId in its path an counterpart using a sophoraId in the path has been created. There are either new endpoints with the suffix bySophoraId or the existing endpoints can now consume sophoraIds and externalIds. Using endpoints with externalIds is still possible but marked as deprecated and the usage of deprecated methods is documented inside the log file. UGC has been refactored to use internally only endpoints with sophoraIds. This includes the taglib.

We recommend to use only endpoints with sophoraIds in order to be robust concerning usage of special characters as part of externalIds.

Deprecated method in the interface for TimingActionScripts

The method com.subshell.sophora.api.scripting.ITimingActionScript#processDocument(java.lang.String) is now a deprecated default method and will be removed in version 4.0.0. Please make sure to adapt all your implementations. The method is replaced by com.subshell.sophora.api.scripting.ITimingActionScript#processDocument(java.util.UUID). As both methods are default functions, it is possible to implement the one or the other in 3.0.0.

lock and unlock throw ItemNotFoundExceptions

The ContentManager methods for locking/unlocking documents and getting the lock state (and therefore on the client side the SophoraClient) now throw an ItemNotFoundException when no document for the given UUID exists. If you have scripts or tools in which you rely on the methods not to throw an exception, you have to catch the exception now.

Sophora Commons Dependencies

Sophora Commons has a dependency to Apache Commons DBCP. Now this Maven dependency is optional. If you require this depdency in your project you have to add it explicitly.

<dependency>
	<groupId>commons-dbcp</groupId>
	<artifactId>commons-dbcp</artifactId>
	<version>1.4</version>
</dependency>

Noteable API Changes

The method ItemPath.getIndex() may now return negative values. The special value ItemPath.ALL_ITEMS_INDEX may be returned by this method. To check if all items with the name of the path are denoted use the method ItemPath.isForMultipleItems().

AV-Tool/YouTube-Connector

The configuration property akamaiUrlPrefixes has been deprecated with version 3.1.0 of the AV-Tool/YouTube-Connector. It will be removed with version 5.0.0. Please use akamaiUrlPatterns instead.

Updated SFTP client

With version 3.5.0 of the YouTube Connector, the outdated ssh-rsa will not be supported anymore by default. You will either need to update your server (SFTP target) to support ssh-rsa2 or add the following Java options to your .conf file to re-enable ssh-rsa:
"-Djsch.server_host_key=...,ssh-rsa -Djsch.client_pubkey=...,ssh-rsa"

Sophora Repo Exporter

Since version 3.1.9, a referenced document (according to configured maxRecursionDepth) will be exported if the recursionCriteria matches or, additionally, if no recursion criterion is configured in the corresponding "documents" block. "documents[].maxRecursionDepth" is now also applied in daemonMode.

TableStar