When 2.x is upgraded to 3.x, an error of className inconsistency is reported

[SuperCarrys]

The reason is that the 3.x version and 2.x have different structures for storing data in zk. The className of 3.x is stored under the jobRootNode, while the 2.x version is stored under the config node, and the 2.x is upgraded to In 3.x, an error will be reported when judging the className, but I read the source code, and the code for judging the task className is as follows:

private void checkConflictJob(final String newJobClassName, final JobConfiguration jobConfig) {
    if (!jobNodeStorage.isJobRootNodeExisted()) {
        return;
    }
    String originalJobClassName = jobNodeStorage.getJobRootNodeData();
    if (null != originalJobClassName && !originalJobClassName.equals(newJobClassName)) {
        throw new JobConfigurationException(
                "Job conflict with register center. The job '%s' in register center's class is '%s', your job class is '%s'", jobConfig.getJobName(), originalJobClassName, newJobClassName);
    }
}

Among them, null != originalJobClassName is to judge whether there is a className under the jobRootNode node in zk, but the judgment here is not null. I found that this String will always be referenced in the test, so null != originalJobClassName is always true, even if the string is an empty character string, so I think, is it possible to change to

    if (StringUtils.isNotBlank(originalJobClassName) && !originalJobClassName.equals(newJobClassName)) 

In this way, the desired judgment logic can be achieved. May I ask if the official can modify it in this way? Is there any situation that I have not considered?

[SuperCarrys]

升级3.x后 ，job会判断任务根节点下存储className是否和当前任务相同，明显此时是没有的，
但是代码里做了!=null的判断，但这里的originalJobClassName在任务节点存在时不可能为null，且�方法开头已经做了任务节点是否存在的判断，所以这里判断!=null是没有意义的，要判断originalJobClassName是不为空，�判断逻辑应为
if (StringUtils.isNotBlank(originalJobClassName) && !originalJobClassName.equals(newJobClassName))

[linghengqian]

• @SuperCarrys you want to submit a PR?

[samiya2804]

The error of class Name inconsistency that you're encountering when upgrading from version 2.x to 3.x of a software typically happens because:

1. In the new version, the naming conventions for classes might have been altered.
2. Some classes from version 2.x might have been refactored or deprecated in version 3.x, leading to inconsistencies when referencing those classes in your existing code.
3. Sometimes, the namespaces or packages in which classes are defined might have changed, leading to this error when your project is still referencing the old paths.

How to resolve it 👍 :

1. If specific class names have changed, a global find and replace for the old class name with the new one can help resolve the issue.
2. Update Imports: Ensure that all class imports or references are updated to match the new naming or location scheme.

[linghengqian]

@samiya2804 I have to assume you don't actually use elasticjob unless you plan on submitting a PR.