-
Notifications
You must be signed in to change notification settings - Fork 87
Description
We have introduced mmm dependencies in devon4j for the following reasons:
- entity interfaces and base classes
- advanced exception support
- NLS/I18N/L10N
The entity stuff caused a strong coupling to a library not world-famous and causing some concerns.
I therefore decoupled things and split mmm-util into many smaller modules a long time ago.
We had removed the dependencies from entities so they do not depend on mmm anymore.
However, the decoupling of mmm has never been completed as those who requested had no more interest in it.
The advanced exception support is nice but in the end it is a matter of more or less one class as shown by the new mmm libs making the NLS optional. We could therefore decide to "copy" that single class into the app template and simply remove all mmm dependencies from the code-base.
The only remaining problems that still have to be solved for this are:
1.
Line 133 in 3c38fa5
| } else if (exception instanceof NlsRuntimeException) { |
Here we need a common base exception to depend on in order to distinguish between "buisness exceptions" to revel with full error message text to outside and "technical exceptions" that are not revealed due to security (OWASP sensitive data exposure). If we stip out mmm we need to find a different "contract" to make this distinction or we simply also "move" the
RestServiceExceptionFacade from our module to the app template.
devon4j/modules/cxf-client/pom.xml
Line 32 in 3c38fa5
| <artifactId>mmm-util-exception</artifactId> |
Can IMHO be removed without impact if next issue is addressed.
Line 30 in 3c38fa5
| return new ServiceInvocationFailedException(cause, message, code, uuid, service); |
We could simple create our own exception for this and remove the dependency.
NLS support and features would be lost but most probably they are not needed.
devon4j/modules/http-client/pom.xml
Line 31 in 3c38fa5
| <artifactId>mmm-util-exception</artifactId> |
Can IMHO be removed without impact.
See also issue #449 that I will close and replace by this one.
The biggest problem with this story is that existing projects that want to update to a latest devon4j version then would get the modules without this mmm dependency & coupling and could run into incompatibilities if they are using the mmm-library to define their exceptions and maybe even use its NLS features.