Update deprecated Camunda subsystem code usages

[danielkelemen]

Acceptance Criteria (Required on creation)

• WildFly 27 compatibility mode is removed (potentially with https://github.com/camunda/camunda-bpm-platform/issues/3746). Prerequisite as some of the new API is not supported in WildFly 27 and potentially WildFly29.
• Our WildFly subsystem extension use of deprecated Wildfly/Jboss APIs is reduced.

Hints

• JBoss
  • org.jboss.msc.service.ServiceBuilder.addDependency(ServiceName, Class, Injector)
  • Use requires(ServiceName) instead.
  • org.jboss.msc.service.ServiceTarget.addService(ServiceName, Service)
  • Use addService() instead.
  • ❗ pay attention of how MscManagedProcessApplication is registered as a child and ensure process applications service name is correctly resolved (test failure, code revert)
  • org.jboss.msc.value.InjectedValue<T>
  • Use org.jboss.msc.service.ServiceBuilder.requires(org.jboss.msc.service.ServiceName) method instead.
  • org.jboss.msc.inject.Injector<T>
  • Use org.jboss.msc.service.ServiceBuilder.provides(org.jboss.msc.service.ServiceName) method instead.
  • org.jboss.msc.service.ServiceBuilder.addAliases(ServiceName...)
  • Use provides(ServiceName) instead.
  • org.jboss.threads.ExecutionTimedOutException
  • Remove, it's not thrown anymore.
  • org.jboss.modules.ModuleIdentifier
  • This class has been deprecated in favor of name strings; however, programs using identifiers will continue to function correctly.
  • org.jboss.modules.Module.getIdentifier()
  • Use getName() instead.
• WildFly
  • getServiceTarget() in org.jboss.as.server.deployment.DeploymentPhaseContext has been deprecated and marked for removal
  • Use getRequirementServiceTarget() instead.
  • getServiceTarget() in org.jboss.as.controller.OperationContext has been deprecated and marked for removal
  • Use getCapabilityServiceTarget() instead.
  • org.jboss.as.controller.AbstractAddStepHandler.AbstractAddStepHandler(AttributeDefinition...)
  • Use default constructor instead. (https://github.com/camunda/camunda-bpm-platform/pull/4044/commits/12d89d874f41abec925318963a0fae7b77ed9343)
• Java
  • java.lang.Class.newInstance()
  • Use Constructor.newInstance method instead.
  • SecurityManager & AccessController in Tccl.runUnderClassloader
  • https://openjdk.org/jeps/411

    In feature releases after Java 18, we will degrade other Security Manager APIs so that they remain in place but with limited or no functionality. For example, we may revise AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager always to return null. This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing so declines to an acceptable level.

  • Decision: no action. Leave the code.

Out of scope

• adoption of org.jboss.msc.Service

Links

Breakdown

### Pull requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4111

[yanavasileva]

Removing potential label as the ticket will not be tackled in 7.20

[yanavasileva]

When working on this please watch out for this issue: https://github.com/camunda/camunda-bpm-platform/issues/3584#issuecomment-1723338290 More input: https://github.com/camunda/camunda-bpm-platform/issues/3584#issuecomment-1727604281

[yanavasileva]

Thoughts on this task: We might need to consider not only moving away from deprecated API. But first check how subsystems are written these days and learn from it.

[yanavasileva]

when adjusting the code in ProcessApplicationStartService#start to register the process application service:

      MscManagedProcessApplication managedProcessApplication = new MscManagedProcessApplication(processApplicationInfo, processApplication.getReference());
      ServiceBuilder<?> serviceBuilder = context.getChildTarget().addService();
      serviceBuilder.provides(serviceName);
      serviceBuilder.setInstance(managedProcessApplication);
      serviceBuilder.install();

doesn't pass the name correctly and can't be use in the tracking service ServiceTracker#handleEvent.

When ServiceTarget#addService() API is used the service name (link) is not populated correctly so it ends up with a new value. That leads to the above error but also to failure when container.dumpServices(); (link) is used. Therefore, that seems as a potential bug in JBoss MSC API.

Decision: Use ServiceTarget#addService(serviceName) for the time being to ensure correct name resolving.