EDIT

This is strange, the actual method getVocRepresentation_L10n_abbreviatedLabel() is never called in cdmlib so I don't understand why an NPE can be thrown.

I fixed the NPE so it does not throw an exception anymore. However, we need to discuss how the TermDTO should behave. Currently the constructor only takes the vocabulary.uuid and therefor no representations for vocabulary are available. Do we need those?

As said before the method is never called directly in cdmlib. Only jason seems to call it during serealization. If none of the webservice users(probably only the dataportal) needs the label we should mybe remove this method.

This issue came with commit cdmlib:71559ffe9c (KL, 2021-09-15) which removed vocRepresentations from the termDTO.

KL + AK can you please both check if you think the vocabulary representation is always needed in this DTO or only if it is explicitly set via setVocabularyDto(TermVocabularyDto vocabularyDto) method or by using the factory method fromTerm(...)?

I give this ticket first to AK for check if the method is needed at all. If yes, we should have some tests that guarantee that voc labels are available in the context where it is needed.

this method is only used in the TaxEditor:

eu.etaxonomy.taxeditor.store/src/main/java/eu/etaxonomy/taxeditor/view/search/facet/term/TermSearchResult.java:            
facets.add(new Facet(((TermDto)content).getVocRepresentation_L10n(), termType!=null?termType.getLabel():null));

thus passing the ticket to you Katja

Added the vocDto to termDto when creating the termDto because the voc representations are needed for the term search. please review, if everything else still works. Already tested the advanced search for e+m

1. I think adding the VocDto to the termDTOs bloats the reponses with a lot of redundant information. In most cases the terms returned by /description/namedAreasInUse.json will belong to the same vocabulary. Adding the vocabulary uuids to the termDTO would be much more efficient. If needed, we could introduce a TermListDTO which allows for a normalized representation of termDTOs and VocabDTOs.
2. In the reponse of http://test.e-taxonomy.eu/cdmserver/euromed/description/namedAreasInUse.json the vocabularyDto is always null, so something is not working as expected here, otherwise this it not really relevant if we agree in not adding the vocDTo to the termDTOs

Andreas Kohlbecker wrote:

1. I think adding the VocDto to the termDTOs bloats the reponses with a lot of redundant information. In most cases the terms returned by /description/namedAreasInUse.json will belong to the same vocabulary. Adding the vocabulary uuids to the termDTO would be much more efficient. If needed, we could introduce a TermListDTO which allows for a normalized representation of termDTOs and VocabDTOs.
2. In the reponse of http://test.e-taxonomy.eu/cdmserver/euromed/description/namedAreasInUse.json the vocabularyDto is always null, so something is not working as expected here, otherwise this it not really relevant if we agree in not adding the vocDTo to the termDTOs

The vocabulary Dto is added in the dao method, so I changed the name of this method to findByTitleAsDtoWithVocDto, actually it is used only for the term search, where the vocabulary information is needed.

I think in general this ticket is fixed as the webservice and TaxEditor do use 2 different methods to initialize the TermDTO (with or without full vocabulary DTO). So I suggest to close it once KL has reviewed my last changes.

However, it shows the DTO handling is still very chaotic and urgently needs more structure. But this needs to be done in another context I guess.

This works as expected.