Add default visibility implementations

[Sebastian Daschner]

It would reduce boilerplate if JSON-B implementations were required to ship with some often-needed visibility strategies, such as (up for discussion):

• PropertyNamingStrategy.PUBLIC_PROPERTY: Use public getters / setters, or public fields (if no corresponding getter / setter) for (de-)serialization. Default behavior.
• PropertyNamingStrategy.PUBLIC_GETTER_SETTER: Use public getters / setters for (de-)serialization.
• PropertyNamingStrategy.PUBLIC_FIELDS: Use public fields for (de-)serialization. Corresponding getters / setters that exist for the fields must be used.
• PropertyNamingStrategy.FIELDS: Use fields (of any visibility) for (de-)serialization. Corresponding getters / setters that exist for the fields must be used.

Maybe add others as well.

For convenience, these constants should be added to the PropertyNamingStrategy interface.

[Romain Manni-Bucau]

Hi @sdaschner ,

think you misused naming strategy and intended to use PROPERTY_VISIBILITY_STRATEGY and PropertyVisibilityStrategy, right?

Now I'd like to give the feedback that this is what is in bean validation and it is likely never used and defaults are likely sane and customizable through PropertyVisibilityStrategy or @JsonbVisibility. So I wonder if you can detail what is the "boilerplate" you are talking about? Just having default implementations? Kind of jsonbConfig.withPropertyVisibility(), jsonbConfig.withFieldVisibility()?

My 2 cts would be that I think field and property built-in values are enough

Hope it makes sense,

Romain

[Andrew Guibert]

Assuming Sebastian meant PropertyVisibilityStrategy with his suggestions instead of PropertyNamingStrategy, I think the following would be OK to add:

• PropertyVisibilityStrategy.PUBLIC_PROPERTY: Use public getters / setters, or public fields (if no corresponding getter / setter) for (de-)serialization. Default behavior.
• PropertyVisibilityStrategy.PUBLIC_GETTER_SETTER: Use public getters / setters for (de-)serialization.
• PropertyVisibilityStrategy.PUBLIC_FIELDS: Use public fields for (de-)serialization. Corresponding getters / setters that exist for the fields must be used.

I do no think this one should be added:

• PropertyNamingStrategy.FIELDS: Use fields (of any visibility) for (de-)serialization. Corresponding getters / setters that exist for the fields must be used.

Because it encourages illegal access to non-public members which will make it harder to migrate applications past Java 8.

[Romain Manni-Bucau]

@aguibert field is fine and will stay one of the most used option (actually only property and field are used in practise cause programming styles are generally exclusive). Java9 does not change that, it just requires you to write your module info properly if you write a module which will not be mainstream for years, in particular with graalvm being a thing now, so no worry on field access.

[Andrew Guibert]

true, if the app's module-info opens the package containing the JSON-B models then it will work OK, and if a user has their app modularized they should be familiar with the concept of opening up packages.

[José Carlos Bran]

Disculpen, tengo el siguiente objeto que deseo convertir en un JSON, al momento de convertirlo invoca los metodos publicos de la superclase, de que forma puedo limitar que solo se invoquen los metodos publicos del objeto en cuestión, sin que se ejecuten los metodos heredados

@DaTa
public class UserModel extends JBSqlUtils implements IsResource {
@JsonbProperty("USUARIOIDENTITY")
private Integer USUARIOIDENTITY = 0;

@JsonbProperty("USUARIO")
private String USUARIO;

@JsonbProperty("USUARIO_DE_RED")
private String USUARIO_DE_RED;

@JsonbProperty("ROL")
private Integer ROL;

@JsonbProperty("PASSWORDUSER")
private String PASSWORDUSER;

@JsonbProperty("Nombre")
private String Nombre;

@JsonbProperty("family_name")
private String family_name;

@JsonbProperty("given_name")
private String given_name;

@JsonbProperty("CUI")
private String CUI;

@JsonbProperty("Telefono")
private String Telefono;

@JsonbProperty("Correo")
private String Correo;

@JsonbProperty("ESTADO")
private Boolean ESTADO = true;

@JsonbTransient
@JsonbProperty("TokenActual")
private String TokenActual;

@JsonbTransient
@JsonbProperty("TokenAnterior")
private String TokenAnterior;

public UserModel() {
    try {
        this.setTableName("USUARIO");
    } catch (Exception e) {
        LogsJB.fatal("Excepción disparada al inicializar el controlador: " + ExceptionUtils.getStackTrace(e));
    }
}

}

y acá esta el servicio

@path("/usuarios/verify")
@post
@consumes(MediaType.APPLICATION_JSON)
@produces(MediaType.APPLICATION_JSON)
public Response verify(UserModel user) {
try {
if (!user.isFull("Correo")) {
return Response.status(Response.Status.NOT_ACCEPTABLE).entity("Asegúrese de enviar la solicitud acorde " +
"al contenido solicitado por el servidor.").build();
}
try {
//Verifica la existencia del usuario en BD's
user.firstOrFailEmail();
return Response.ok().entity(user).build();
} catch (ModelNotFound e) {
user.setESTADO(false);
return Response.ok().entity(user).build();
}
} catch (Exception e) {
LogsJB.fatal("Excepción disparada al verificar la existencia del usuario " + user.toString() + ": " + ExceptionUtils.getStackTrace(e));
return Response.serverError().entity("Sucedio un error al verificar la existencia del usuario").build();
}
}

el problema es que Response.ok().entity(user).build(); 

invoca los metodos publicos heredados.