Timeline for How to untangle a data class where annotations from different frameworks mix?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 30, 2018 at 14:51 | comment | added | scottysseus | You could also skip annotations entirely. Define a single class for each resource, and then e.g. define Dozer mappings in XML from the resource to each of the JSON objects you need. But with this solution, you aren't necessarily saving yourself much configuration - you are just moving it around. | |
| Aug 30, 2018 at 14:46 | comment | added | scottysseus | One alternate approach I thought of that seems hacky is to create your own annotations, and then use reflection to analyze them and then generate SCIM/LDAP annotated classes at runtime. I am not sure if this is even possible, but it would allow you to only maintain one annotated 'copy' of each of your resources. | |
| Aug 30, 2018 at 14:43 | comment | added | scottysseus | I definitely agree that this DSL approach is not easy. However, you can have the generated annotated classes conform to an interface, and have your business logic depend on that interface instead. Thus, I am not sure dependencies would be an issue here. | |
| Aug 30, 2018 at 14:35 | comment | added | Kolargol00 |
This would make my business logic dependent on concrete types ScimAppleSauce and LdapAppleSauce which it should not have to care about. I would prefer to keep these details in their respective serialisation layers. Moreover, writing a DSL seems rather complicated...
|
|
| Aug 29, 2018 at 14:55 | review | First posts | |||
| Aug 30, 2018 at 15:59 | |||||
| Aug 29, 2018 at 14:52 | history | answered | scottysseus | CC BY-SA 4.0 |