eXo-JCR-kernel

Problem analysis

* In cluster mode, the jobs and the triggers are persisted such that when the database has already been initialized we get some warning at server startup because we try to register jobs that have already been defined in the database.

Fix description: update the jobs registration.

* In case the jobs are not persisted, keep the old behavior to remain backward compatible.

In case the jobs are persisted, when we try to register a job, we first check whether it exists already.

If it doesn't exist, we register it.

Otherwise we continue to check if the job that we try to register is the same as the one already registered.

If it is the same, we skip the registration and log a message in debug level. Otherwise we raise an exception indicating that a job already exists.

Problem analysis

* For object parameter, the kernel uses reflection to provide all the fields.

The kernel assumes that object parameters are only simple Bean Objects with simple fields.

However, in case of PLF we have some object parameters whose fields are actually services provided by the ExoContainer.

As consequence, the kernel tries to convert it into an object parameter recursively which finally causes a StackOverFlowError.

Fix description

* Before converting a field into an object parameter, we first check if the field is not a service provided by the ExoContainer in case we are serializing a configuration to limit the risk.