Messages.properties Middleware

Support
#1

How can set and get messages from middleware service ? Should I create a file messages.properties into …core…\service folder ?

#2

Hi,

messages stored in properties file are read-only, so you can only get…

what’s your specific use case? Because getting localized messages from a service smells like a bad choice, but it’s difficult to reason about without some more context.

Bye
Paolo

#3

Simply I am doing few rest api, and I want return message result

#4

You can easily use Messages on middleware, just use getMessage(String pack, String key) method and pass package with your messages.properties to pack parameter.

String msg = messages.getMessage("com.haulmont.cuba.demo", "my.message");
#5

Adding to @artamonov response, consult this doc topic for more info: Messages - CUBA Platform. Developer’s Manual

Regarding the use of localized messages in API responses: never return localized messages as the only response for an API request. It is ok to use them to add more context to an error in a response.

CUBA promotes an hybrid approach in developing remote APIs, and that’s a major concern IMHO for developers without much experience in developing production APIs.

All the endpoints provided by CUBA, with the exception of the services one, follow a REST-like architecture, or resource-oriented (Richardson Maturity Level 2, so not truly RESTful). On the other hand, the services endpoint follows the RPC style (R.M. Level 1: you call a method over HTTP, and most of the time you get a 200 response, even for errors that could be expressed by an HTTP status code, for example not found).
For a more in-depth discussion on that matter read this thread. My suggested approach to services in CUBA is outlined in this post.

The aforementioned approach is somewhat advanced, as it involves writing custom MVC controllers, but even if you don’t want to take that route today, I suggest to define at least some POJOs to be returned by your services, and stick to them (it should become your internal standard).

One viable approach could be to mimic the JSON-RPC behaviour. Define something like the following POJOs, and use them for EVERY response in your services:

public class RpcResponse<RpcResult> {
    /*
      the actual service method result, JSON serialized
     */
    public RpcResult result;
    /*
      a collection of 0..* errors returned by the service method
     */
    public Collection<RpcError> errors;
}

public class RpcError {
    /* the actual error code; use for example HTTP error codes for basic things,
       like 404 (not found), and use the 9 prefix for business error codes
       (like 901 - insufficient funds)
     */
    public int code;
    /*
       this is the unique message key for looking up localized message
       (for example: "POSService.insufficientFunds")
     */
    public String messageKey;
    /*
      this is the actual localized (or not) message, retrieved by best guessing
      the current user's locale (but you can stick with english only, as I usually
      prefer localising in the upper UI layer)
     */
    public String message;
}

Hope this helps in your journey to CUBA proficiency :wink:

Paolo