Parse problems with inherited JAVAX WS CORE fields

Asked

Viewed 24 times

0

I have a return class, which has its attributes set to return in the response in json or xml, depending on the query.

I need to insert two new fields in this return, but they are very specific, that is, other services will not use, but due to the abstraction that we have, necessarily need that the return object is the same.

Well, I had the idea to extend an object to that kind of feedback. something like:

The mother class would be this:

    public class Retorno implements Serializable {

/**
* 
*/
private static final long serialVersionUID = -1L;

private String id;

private String descricao;
//getters and setters
}

And the daughter class:

public class RetornoExtendido extends Retorno {

/**
* 
*/
private static final long serialVersionUID = 1L;

protected String detalheRetornoExtendido;
/getters and setters
}

Well, all right, the application behaves as expected and the attributes are filled correctly.

However, when parsing for json, the child class fields are ignored, it would look something like:

{
"retorno": {
    "id": 1,
    "descricao": "alguma decricao"
}

}

even if the child class field is filled.

the return class defined for the Response Builder, is the mother class.

something like

Response.status(Status.OK).entity(retorno).build();

Where Return is defined as:Retorno retorno = servico.processarRetorno(parametros);

where processing returns an instance of the child class.

I didn’t find anything related and for me it doesn’t make much sense, maybe I’m getting lost in some detail.

1 answer

0

It was not very clear how you generate the return but seems to me a problem that can be solved using Decorator design pattern. Simply instead of extending the mother class you create an interface:

public interface Retorno implements Serializable { 
   // seus métodos 
   public String retornaJson();
}

Your mother class then implements Return:

ṕublic class RetornoImpl implements Retorno { 

   // implementação atual 
   public String retornaJson {// }
}

Its Decorator class also implements Return but has a builder who also receives a class that implements Return:

public class RetornoDecorator implements Retorno {
      Retorno retorno = retorno;
      public RetornoDecorator(Retorno retorno) {
         this.retorno = retorno;
      }

      // implementações da interface Retorno usam as implementações do campo retorno
      public String retornajson {
           return this.retorno.retornaJson(); 
      }
     
}

In use you must extend the class Retornodecorator:

public class RetornoDecoratorEstendido extends RetornoDecorator {
     public RetornoDecoratorEstendido(Retorno retorno) {
          super(retorno);
     }

     public String retornaJson() {
          return super.retornaJson() + " retornoJsonEstendido ";
     }     
}

Note that they all implement the Return interface which facilitates code re-factoring and new extensions that are created. To learn more, see about standard Decorator in wikipedia (most complete in english).

  • I’m going to take this test, Emerson, thank you very much, I hadn’t thought of that pattern. But as you said that it was not very clear, the issue of inheritance works, I have the fields filled, but in solving Moxy to transform the object that I Seto in Response in Json/XML, these fields of the daughter class are ignored, even if they are filled. Anyway, I’ll take this test! Thanks again.

  • Don’t forget to update us with the solution or update the issue with new information so the community can help.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.