#571: simplified archetype

[hohwille]

Implementation of #571 Changes and TODOs:

• modules removed - now single and simple flat maven project
• scope package segment removed
• no more dependencies to devon4j-* or mmm-*, just vanilla spring-boot, etc. to get started.
• [x] TODO: @Inject not working in JUnits
• [x] Flyway bean cannot be injected (was most likely the same problem with JakartaEE - we simply deleted DbTestHelper).
• [x] URL convention changed from services/rest to services for REST services. IMHO this is undesired and should be fixed by some CXF config (if CXF is capable to do so). Otherwise our service-client will not work seamlessly. However, new convention from CXF starter. PR to reconfigure this is welcome...
• CXF does not startup without REST service, so I included a stupid hello world REST serivce that projects have to delete after creating their own REST service(s). Would be nicer to make it work without the hello world REST service.

Featurelist:

• JAX-RS REST Services work out of the box including JSON mapping (only flaw is that app does not start if no REST service is present due to cxf autostarter).
• Rest-Exception facade with protection about sensitive-data-exposure but ability for "business exception" still included
• Rest-Exception mapping also for access-denied errors.
• Beanmapping works (via Orika) and support proper @Version handling for optimisitc locking.
• spring-data Repos, hibernate entities, etc. working out of the box.
• LIMITATION: since we removed devon4j-spring-data module there is no comfortable way to implement QueryDSL queries OOTB in Repo interfaces and you have to follow the ugly and flawed spring pattern to write such queries resulting in 3 types per Repo instead of just 1.
• Jackson config infrastructure including polymorphic custom mappings.
• Authentication (Spring-Security) starting point - currently still with ugly inMemoryAuthentication and hardcoded PWD.
• TODO: can we get rid of this somehow? Do we need JWT authentication by default and require Keycloak that we would add via docker to get started easy? Sounds all complicated...
• Authorization with support to group permissions
• Therefore disabling ROLE_ prefix in spring-security
• OOTB logging of performance and status of every request (PerformaceLogFilter)
• Encoding set to UTF-8 for all requests by default.
• TODO: Should we remove CSRF stuff and move to docs? IMHO yes
• TODO: I removed batch from archetype entirely. Do we need anything for batches? I would rather suggest docs explaining how to add this manually...
• I also removed the enterprise nonsense (EAR support) from the archetype.
• TODO is there are reasonable argument to change from bootified WAR to bootified JAR?

[hohwille]

For some strange reason dependency-injection does not work in the spring-tests but I have not changed anything related. I get NPEs as @Inject annotation is not honored and populated by spring. I debugged into the deepest core of spring and found out that DependencyInjectionTestExecutionListener gets invoked as expected and also triggers AutowiredAnnotationBeanPostProcessor that also properly registers javax.inject.Inject. Further, autowireBeanProperties calls populateBean that should do the actual job. It then also finds the annotated fields but now something strange happens: Both the requiredType and the type are javax.inject.Inject (see red markers). However, spring only resolves 2 mappings - one for javax.inject.Named and the other for javax.inject.Qualitifer. So the one for javax.inject.Inject is missing and hence null is returned with the result that the field is ignored for injection. IMHO this is a bug in spring(-test), but as we have tests working in an analogue scenario I am clueless what is causing this bug exactly. For the record: it works if I use @Autowired instead of @Inject - seems to be a really wired and crazy spring but - what a pitty.

[hohwille]

So also this CXF autostarter is causing problems: when you do not have any service, it makes your spring-boot app fail:

[INFO] Caused by: org.apache.cxf.service.factory.ServiceConstructionException: No resource classes found

Actually the exception handling is so lousy, that it is really hard to find this valuable root cause in the logs and draw the correct conclusions from it.

[hohwille]

So as expected with the workarounds the tests now succeeded:

[INFO] [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

IMHO this reveals the following spring related bugs/issues:

• @Inject stopped working in JUnit - however, when I do not upgrade spring-boot version, I still get the same error and why did this work before and also works in the JUnits of the modules?
• Flyway bean can not be injected anymore - if annotated with @Autowired we get the error that no such bean exists. What caused this to break?

But there is even more fun: I activated OWASP dependency-check and get this errors now:

Error: [ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0': 
Error: [ERROR] 
Error: [ERROR] jakarta.enterprise.lang-model-4.0.1.jar: CVE-2020-36460
Error: [ERROR] querydsl-core-5.0.0.jar: CVE-2022-31548
Error: [ERROR] spring-boot-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-core-5.3.22.jar: CVE-2016-1000027
Error: [ERROR] spring-data-commons-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-data-jpa-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-security-core-5.7.2.jar: CVE-2018-1258, CVE-2016-1000027
Error: [ERROR] spring-security-crypto-5.7.2.jar: CVE-2018-1258, CVE-2016-1000027
Error: [ERROR] spring-security-web-5.7.2.jar: CVE-2018-1258

Whoa - so just looking at the very first match https://nvd.nist.gov/vuln/detail/CVE-2020-36460: So depdendency-check wants to tell me that jakarta.enterprise.lang-model-4.0.1.jar is affected by a RUST bug, come on guys what are you smoking? Seems that also dependency-check and CVE bug databases got broken and turned useless.

[hohwille]

But there is even more fun: I activated OWASP dependency-check and get this errors now:

Error: [ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0': 
Error: [ERROR] 
Error: [ERROR] jakarta.enterprise.lang-model-4.0.1.jar: CVE-2020-36460
Error: [ERROR] querydsl-core-5.0.0.jar: CVE-2022-31548
Error: [ERROR] spring-boot-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-core-5.3.22.jar: CVE-2016-1000027
Error: [ERROR] spring-data-commons-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-data-jpa-2.7.2.jar: CVE-2016-1000027, CVE-2022-22965
Error: [ERROR] spring-security-core-5.7.2.jar: CVE-2018-1258, CVE-2016-1000027
Error: [ERROR] spring-security-crypto-5.7.2.jar: CVE-2018-1258, CVE-2016-1000027
Error: [ERROR] spring-security-web-5.7.2.jar: CVE-2018-1258

I could fix this by updating the version of the dependency-check plugin. Now only two reasonable CVEs remain:

[INFO] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8,0':
[INFO]
[INFO] querydsl-core-5.0.0.jar: CVE-2022-31548(9.3)
[INFO] spring-web-5.3.22.jar: CVE-2016-1000027(9.8)

• https://nvd.nist.gov/vuln/detail/cve-2016-1000027 - will not be fixed by spring so we IMHO need to put it on an exclusion list. We are not using or recommending Java serialization for data-transport at all (e.g. never use HttpInvoker instead use REST, SOAP, or gRPC).
• https://nvd.nist.gov/vuln/detail/cve-2022-31548#range-8131735 - sill a false positive. I found a bug issue for this one: https://github.com/jeremylong/DependencyCheck/issues/4690

[hohwille]

@baumeister25 thanks for your review. Some things can be quickly addressed but mainly I see the need for a longer discussion to reach an alignment in a meeting. Can you arrange this?

[baumeister25]

@baumeister25 thanks for your review. Some things can be quickly addressed but mainly I see the need for a longer discussion to reach an alignment in a meeting. Can you arrange this?

@hohwille Yes, I totally agree. That's also the reason why I did not comment all your comments ;-). I'll setup a meeting with Malte, Jan-Gerrit you and me. I would start in this small round and if we feel that we need further input we can define the participants in that meeting.