Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleXperienCentral 10.22.0

 XperienCentral 10.22.0

See also the XperienCentral 10.22 Changelog for information on the issues that have been fixed and other product improvements.

DependencyManager

In XperienCentral 10.22.0, the DependencyManager implementation has been changed. This has an impact for plugins that use the DependencyManager object in their Activator class with package name org.apache.felix.dependencymanager. In XperienCentral versions prior to 10.22.0, the library DependencyManager version 3.0.0 and DependencyManager Compat 3.0.0 were available. In XperienCentral 10.22 and higher, the Compat library has been removed.

If the Compat library class org.apache.felix.dependencymanager.DependencyManager was present, it was used as a compatibility version for the DependencyManger 3.0.0 (non Compat). All DependencyManager object implementations in plugin Activators where the version of Compat is used will no longer work in XperienCentral versions 10.22.0 and later. In the locations where this variant is used, you must refactor to the DependencyManager 3.0.0/4.4.1 (org.apache.felix.dm.DependencyManager) (non Compat) variant. 

For project plugins the refactoring should be straightforward when upgrading to XperienCentral 10.22 or higher. For plugins that must be deployed on all XperienCentral versions (reusables), a fix is available and implemented in the reusable Utility Services (version 1.6.2).

You must refactor your plugins or reusables in the following cases:

Project Plugins 

If your Activator uses the DependencyManager object with package name org.apache.felix.dependencymanager, change this to org.apache.felix.dm and replace the createService() method with createComponent(). The Service class is no longer available. If your Activator overrides the init() method, refactor this to override the start method and retrieve the DependencyManager object from the ComponentBundleActivatorBase class.

Reusable Plugins 

The same situation applies as above, except you need to add an extra subclass in the Activator class in order to be compatible with XperienCentral versions 10.22.0 higher. If the reusable already uses the Utility Services dependency, you can use the com.gxwebmanager.solutions.wmsutilityservices.osgi.CompatibleActivatorBase in your Activator class. If not, you can add the dependency or copy the class to your own plugin, however, this is not recommended. Also add the  org.apache.felix.dm.*;version="[3.0,5.0)" import package to your pom.xml maven-bundle-plugin. This will ensure that the old 3.0.0 and new 4.4.1 DependencyManager version can be used by your reusable.

If your Activator class uses the createServiceDependency() method to add a Service to the DependencyManager (in REST cases for example), you must refactor this implementation to use the addServiceDependency() method from the CompatibleActivatorBase class in reusable Utility Services.

If your Activator class does not use a DependencyManager object and the Activator class extends from the XperienCentral ComponentBundleActivatorBase class, no refactoring is required. You may need to build your plugin against the XperienCentral 10.22 or newer version.


Note

The required changes described above should be sufficient to make your plugins compatible with XperienCentral 10.22.0 and higher. In some cases, however, this may not be sufficient and further refactoring may be needed. Contact your GX consultant if you have any questions or are unable to get your plugins to work.


When refactoring is done finished and XperienCentral has been upgraded to this version or higher, the DependencyManager Compat 3.0.0 bundle can be unstalled.

Custom Facets

Two facets for the keywords field have been added in this release. In order to be able to uniquely identify a facet, changes have been made that affect custom made facet components. The following changes must be made in your project code:

  • In the interface SearchFacetComponentDefinition, the method getIdentifier() has been added. Every class implementing this interface must therefore add this method. The identifier should be a unique string identifying the facet.
  • The constructor of the class SimpleSearchFacetComponentDefinition has been changed. It now includes a parameter for the unique identifier. The new signature is:

    SimpleSearchFacetComponentDefinition(String identifier, String widgetId, Class<?> valuesType, List<String> path, int priority, Map<Locale, String> titles, int position, Map<String, String> properties

    All references to this constructor should be changed.
  • For projects or reusables that use custom Dojo facet search code (those that extend \wmpgui\widgets\advancedsearch\facet\FacetWidget.js) there are some more API changes that you must be aware of:
    • FacetWidget now has an extra member for the facet identifier. This is accessible in widgets via the FacetWidget method called getFacetIdentifier(). Also, the constructor for it has been changed to:

      FacetWidget(fieldIdentifier, facetTitle, facetProperties, facetIdentifier)

    • If you define a FacetQuery in your custom facet widget, the constructor for this object is extended with a parameter for the facet identifier. The constructor is now:

      FacetQuery(fieldIdentifier, facetIdentifier, facetParameters, valueCountQueries, valuesFilter, valuesLimit)

    • If you define FacetDefinition objects in your custom widget code, the constructor has been changed to:

      FacetDefinition(fieldIdentifier, name, properties, facetIdentifier, FacetWidget)


It will depend on your specific use case how your code should be changed. It may be the case, for example, that your custom code uses a FacetQuery just for showing a result set without having to do any filtering. In this case, an empty string can be used for the facet identifier field in your FacetQuery constructor. In other cases where your FacetQuery is indeed bound to a certain facet, you need to use the facet identifier for that facet.

Other Changes

  • The formvalidation.js file in the wmpformpresentation plugin has been changed and needs to be updated when overruled in a custom presentation.
  • The Is Used In widget can now recognize custom media items. You do need to make some modifications to your code, however. See Custom Media Items and the Is Used In Widget.

 

 

 

...