Errors when attempting to create/edit web content from the control panel

Issue

• After to recently migrated from Liferay 7.3 to 2023.q3.7, an error occurs immediately upon entering the edit (or creation) of content (and it continues to reproduce in the JS console when switching languages in the contribution). This error makes content management impossible
• The following JS error is displayed in the browser console when attempting to create or edit new web content

• In addition, the following error trace is also displayed in the Liferay log.

2024-06-27 10:28:27.962 WARN [ajp-nio-0.0.0.0-8009-exec-32][code_jsp:169] {code="404", msg="ProxyServlet: /data-engine/v2.0/data-layouts/4786516/context", uri=/o/data-engine/v2.0/data-layouts/4786516/context}

Environment

• 2023.q3

Resolution

• To determine the cause of the problem, please follow these steps:
  • Retrieve a database entry from the table: configuration_ with configurationId: org.apache.aries.jax.rs.whiteboard.default

configurationid:
org.apache.aries.jax.rs.whiteboard.default

dictionary:
":org.apache.felix.configadmin.revision:=L"2"
application.ready.service.filter="(&(module.service.lifecycle\=system.check)(objectClass\=com.liferay.portal.kernel.module.framework.ModuleServiceLifecycle))"
default.application.base="/rest"
default.web=B"false"
felix.fileinstall.filename="org.apache.aries.jax.rs.whiteboard.default.config"
service.bundleLocation="?"
service.pid="org.apache.aries.jax.rs.whiteboard.default"

• • Verify if their Liferay bundle includes the file: osgi/configs/org.apache.aries.jax.rs.whiteboard.default.config

application.ready.service.filter="(&(module.service.lifecycle=system.check)(objectClass=com.liferay.portal.kernel.module.framework.ModuleServiceLifecycle))"
default.application.base="/rest"
default.web=B"false"

• If there are values in the database and in the configuration as mentioned, you should make the following changes with the portal stopped and then restart the environment:
  • Modify file Liferay_HOME-> osgi-> configs -> org.apache.aries.jax.rs.whiteboard.default.config with the following values:

  • application.ready.service.filter="(liferay.jaxrs.whiteboard.ready\=true)"
    default.application.base="/rest"
    default.web=B"false"

• This change should resolve the problem

Additional Information

• The root cause is that the client's configuration was not using the updated value for: application.ready.service.filter

• The following Gogo shell commands are executed to try to detect the current state of the affected service:

  scr:info com.liferay.data.engine.rest.internal.jaxrs.application.DataEngineRESTApplication
  scr:info com.liferay.data.engine.rest.internal.resource.v2_0.DataLayoutResourceImpl
  scr:info com.liferay.portal.vulcan.internal.jaxrs.feature.VulcanFeature

  Components in a SATISFIED state.

• This issue can occur due to one of the following scenarios:

  • The osgi/configs/org.apache.aries.jax.rs.whiteboard.default.config update might have been unintentionally replaced with its original configuration (from Liferay 7.3) during the Liferay instance's update/migration process.
  • An error might have occurred during the upgrade from the previous version
• When comparing Liferay 7.3 and 7.4, some key changes stand out:

1. 1. Change in application.ready.service.filter:
      In Liferay 7.4, the value of the application.ready.service.filter property was modified as part of the LPS-158528 improvement. This change includes an upgrade process (UpgradeProcess) that should automatically update the value of this property during migration.

   2. Differences in the OSGi configuration of org.apache.aries.jax.rs.whiteboard.default:

      1. In Liferay 7.3, this OSGi configuration is provided through the file osgi/configs/org.apache.aries.jax.rs.whiteboard.default.config->  Reference
      2. In Liferay 7.4, the same configuration is managed internally through an OSGi function and is located within the module portal-remote-jaxrs-whiteboard, specifically in configurator/configurations.json->Reference

Normally, the upgrade process should handle these changes and update the OSGi configuration smoothly. However, if the application.ready.service.filter property was not updated correctly during migration, this could explain the reported behavior.

It is important to verify whether this property was updated correctly, as an incorrect configuration could be the cause of the problem.