Cannot invoke "java.util.Map.get(Object)" because "apijson.orm.AbstractVerifier.ACCESS_FAKE_DELETE_MAP" is null  #654

Activity

1. TommyLemon commented on Dec 18, 2023

   

   TommyLemon

   on Dec 18, 2023

   Member

   More actions

   没有及时初始化导致的 bug，这里应该在 static 代码块加上
   ACCESS_FAKE_DELETE_MAP = new LinkedHashMap<>();
   https://github.com/Tencent/APIJSON/blob/master/APIJSONORM/src/main/java/apijson/orm/AbstractVerifier.java#L133-L150
   

   MultiDataSource 等 Demo 没复现是因为 APIJSONVerifier.initAccess 把它初始化了
   
   ，但如果没有依赖 apijson-framework 并成功调用 APIJSONVerifier.initAccess，ACCESS_FAKE_DELETE_MAP 照样也没初始化，后面 ACCESS_FAKE_DELETE_MAP.get 也会照样报错 NPE。
2. TommyLemon

   added

   Bug 漏洞

   on Dec 18, 2023
3. csx-bill commented on Dec 18, 2023

   

   csx-bill

   on Dec 18, 2023

   ContributorAuthor

   More actions

   jitpack 6.3.0 APIJSON 的jar 包 源码也是不对的，
4. csx-bill commented on Dec 18, 2023

   

   csx-bill

   on Dec 18, 2023

   ContributorAuthor

   More actions

   #652 (comment) 这里我有说明
5. csx-bill commented on Dec 18, 2023

   

   csx-bill

   on Dec 18, 2023

   Last edited by csx-bill

   ContributorAuthor

   More actions

   @Override
   protected String getKey(SQLConfig<String> config, ResultSet rs, ResultSetMetaData rsmd, int tablePosition, JSONObject table, int columnIndex, Map<String, JSONObject> childMap) throws Exception {
       String key = super.getKey(config, rs, rsmd, tablePosition, table, columnIndex, childMap);
       // 前端传参驼峰命名转为蛇形命名
       return JSONResponse.formatUnderline(key, true);
   }
   

   放开这段代码 后 错误日志

   java.lang.IllegalArgumentException: URL 路径 /get/sysUserPage 对应的接口不存在！
   at apijson.router.APIJSONRouterController.router(APIJSONRouterController.java:181)
   at apijson.router.APIJSONRouterController.router(APIJSONRouterController.java:65)

   请求参数

   {
   "SysUser[]":{
   "SysUser":{"realName":"超级管理员"},
   "page":0,
   "count":10
   },
   "total@":"/SysUser[]/total",
   "format":true
   }
6. TommyLemon

   added

   help wanted请求帮助请求帮助

   on Dec 19, 2023
7. TommyLemon commented on Dec 19, 2023

   

   TommyLemon

   on Dec 19, 2023

   Member

   More actions

   这个问题应该和之前的 ACCESS_FAKE_DELETE_MAP = null 无关，应该是用了 apijson-router 但没配置 Document 记录导致
   https://github.com/APIJSON/apijson-router?tab=readme-ov-file#usage
8. henriquejsza commented on Aug 29, 2026

   

   henriquejsza

   on Aug 29, 2026

   Last edited by henriquejsza

   Contributor

   More actions

   Hi @TommyLemon, I re-checked #654 against current master (APIJSONORM 8.3.0, c204638b). It still reproduces in a database-free harness that calls the real AbstractSQLConfig.newSQLConfig(...) path with fake delete enabled:

   • with ACCESS_FAKE_DELETE_MAP == null, GET fails at AbstractSQLConfig.java L6046-L6047 and DELETE at L6197-L6198, with the reported NPE;
   • with a configured User entry (deletedKey=is_del, deletedValue=1), DELETE is rewritten to PUT with content={is_del=1}.

   The map is still declared @NotNull without initialization (AbstractVerifier.java L114-L115). Eager initialization (new LinkedHashMap<>() in the static block) therefore looks like a narrow fix for the null-static-map path.

   One boundary needs maintainer guidance: after eager initialization, DELETE with an empty map or no entry for the table still gets null at L6198 and dereferences it at L6200. Simply skipping that branch would leave the method as DELETE, so I do not want to assume a physical-delete fallback. Would you prefer this PR to stay limited to eager initialization plus database-free regression tests, leaving missing-entry policy separate, or should it also fail explicitly when fake delete is enabled but the table has no configuration (or use another behavior you prefer)?

   I also checked #602/#603; they cover adjacent fake-delete behavior but do not apply this initialization. I have not started a patch so we can align first. If this limited scope is useful, may I take #654 and prepare the PR?
9. TommyLemon commented on Aug 30, 2026

   

   TommyLemon

   on Aug 30, 2026

   Last edited by TommyLemon

   Member

   More actions

   Hi @TommyLemon, I re-checked #654 against current master (APIJSONORM 8.3.0, c204638b). It still reproduces in a database-free harness that calls the real AbstractSQLConfig.newSQLConfig(...) path with fake delete enabled:

   • with ACCESS_FAKE_DELETE_MAP == null, GET fails at AbstractSQLConfig.java L6046-L6047 and DELETE at L6197-L6198, with the reported NPE;
   • with a configured User entry (deletedKey=is_del, deletedValue=1), DELETE is rewritten to PUT with content={is_del=1}.

   The map is still declared @NotNull without initialization (AbstractVerifier.java L114-L115). Eager initialization (new LinkedHashMap<>() in the static block) therefore looks like a narrow fix for the null-static-map path.

   One boundary needs maintainer guidance: after eager initialization, DELETE with an empty map or no entry for the table still gets null at L6198 and dereferences it at L6200. Simply skipping that branch would leave the method as DELETE, so I do not want to assume a physical-delete fallback. Would you prefer this PR to stay limited to eager initialization plus database-free regression tests, leaving missing-entry policy separate, or should it also fail explicitly when fake delete is enabled but the table has no configuration (or use another behavior you prefer)?

   I also checked #602/#603; they cover adjacent fake-delete behavior but do not apply this initialization. I have not started a patch so we can align first. If this limited scope is useful, may I take #654 and prepare the PR?

   @henriquejsza Thank you for your feedback and sugguestion. The NPE bug should be fixed. ACCESS_FAKE_DELETE_MAP should be eager initialized while it hasn't yet.
   https://github.com/Tencent/APIJSON/blob/c204638b5dfe62747f2f373ba8b59259c4ea9cf8/APIJSONORM/src/main/java/apijson/orm/AbstractVerifier.java#L114-L115
   

   When the fake-delete was configured and an error was occurred, it should fail with an Exception, not fallback to real deleting, so that the behavior can be predicted and the error can be warned and noticed, since I think the reason why most developers configure fake-delete is that they don't want the real deleting for certain tables.
   Looking forward to your PR~
10. TommyLemon

    added a commit that references this issue on Aug 30, 2026

    fix: fail fast on invalid fake-delete config

    ...

    cb44b39
11. TommyLemon

    closed this as completedin #875on Aug 30, 2026