Ao utilizar um ExceptionMapper para tratar exceções em uma aplicação Java EE, é comum que exceções lançadas dentro do contexto de um EJB sejam automaticamente encapsuladas em uma EJBException. Esse comportamento pode dificultar a captura e o tratamento adequado da exceção original.

Para evitar que a exceção seja envolvida por uma EJBException, basta anotá-la com @ApplicationException. Essa anotação informa ao container do EJB que a exceção é de aplicação e não deve ser encapsulada automaticamente.

Exemplo de Código

import jakarta.ejb.ApplicationException;
import jakarta.ws.rs.core.Response;
import jakarta.ws.rs.ext.ExceptionMapper;
import jakarta.ws.rs.ext.Provider;

// Definição de uma exceção de aplicação personalizada
@ApplicationException
public class MinhaExcecao extends RuntimeException {
    public MinhaExcecao(String message) {
        super(message);
    }
}

// Implementação do ExceptionMapper para capturar a exceção e gerar uma resposta HTTP adequada
@Provider
public class MinhaExcecaoMapper implements ExceptionMapper<MinhaExcecao> {
    @Override
    public Response toResponse(MinhaExcecao exception) {
        return Response.status(Response.Status.BAD_REQUEST)
                .entity("Erro: " + exception.getMessage())
                .build();
    }
}

// EJB que lança a exceção personalizada
import jakarta.ejb.Stateless;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Stateless
@Path("recurso")
public class MeuRecursoEJB {
    @GET
    public String metodoQueLancaExcecao() {
        throw new MinhaExcecao("Ocorreu um erro específico na lógica de negócio.");
    }
}

Explicação do Código

1. Criação de uma exceção personalizada (MinhaExcecao): A anotação @ApplicationException evita que ela seja encapsulada em uma EJBException.

2. Implementação de um ExceptionMapper: Captura MinhaExcecao e retorna uma resposta HTTP 400 (Bad Request).

3. EJB lançando a exceção: O método metodoQueLancaExcecao() simula um erro que será tratado pelo ExceptionMapper.

Com essa abordagem, garantimos que a exceção seja tratada de maneira controlada e previsível, melhorando a experiência do usuário e a manutenção da aplicação.

Here again, after the annoying 1100 code error when try to run the flutter build ipa command.

Now, the trouble indicates something related to the Provisioning Profile. After two days trying, the solution came after lunch.

Besides the sign in method in XCode was set to automatic, as the flutter pages recommends, the command exits with the following error message:

Provisioning profile doesn’t include signing certificate

So, I took 4 steps to get it done:

• I decided to upgrade the Flutter version;
• Run flutter clean;
• Run flutter build ios;
• Run flutter build ipa -v –release –dart-define=…

And, like magic, the command generated the ipa file.

Foooooo!!! Hope helps others.

To set a different SDK to a project, add the following property to gradle.properties file:

org.gradle.java.home=/usr/lib/jvm/java-11-openjdk-amd64/ 

Other approach, that didn’t work for me is include the following property to the settings.json (Ctrl + P):

If your app is crashing on startup when runnging a AVD, you should analyse the logcat from ‘View > Tool Windows > Logcat.

In my case, the crash cause was:

Caused by: java.lang.ClassNotFoundException: Didn't find class "br.com.sidroniolima.medo_e_delirio_app.MainActivity" 

The problem was at AndroidManifest.xml file.

The activity was pointing to a .MainActivity that is not there. It maybe have been occurred when I configure the flutterfire on project.

The Android Plugin upgrade page shows at the 5th step the following:

Android Plugin update page.

(Optional) If you removed MainActivity.java, update the <plugin_name>/example/android/app/src/main/AndroidManifest.xml to use io.flutter.embedding.android.FlutterActivity. For example:

The solution was replace the old block to the new one. As follows.

<activity
            android:name=".MainActivity"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize">

<activity
            android:name="io.flutter.embedding.android.FlutterActivity"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize">

Existe uma falha de segurança na API Java 3.0 da Cielo que expõe dados da resposta de uma transação.

O método parseResponse da calsse AbstractSaleRequest<Request, Response> chama o sysout com a string do corpo da resposta.

A chamada desse método imprime campos como nome do cliente que consta no cartão de crédito, números do cartão com apenas 6 dígitos omitidos, data de vencimento da cartão e ID do pagamento, entre outros.

Em tempos de LGPD, é inadimissível que isso seja exposto.

Abri um chamado pelo suporte da Cielo mas não surtiu efeito. Abri uma issue no github e até agora não responderam. A API parece abandonada e, portanto, deveria, ao menos, ser considerada depreciada.

A solução foi utilizar a API Rest, que não apresenta essa falha.

Segue  o código do método.

/**
	 * Just decode the JSON into a Sale or create the exception chain to be
	 * thrown
	 *
	 * @param statusCode
	 *            The status code of response
	 * @param responseBody
	 *            The response sent by Cielo
	 * @return An instance of Sale or null
	 * @throws CieloRequestException
	 */
	private Response parseResponse(int statusCode, String responseBody, Class<Response> responseClassOf)
			throws CieloRequestException {
		Response response = null;
		Gson gson = new Gson();

		System.out.println(responseBody);

		switch (statusCode) {
		case 200:
		case 201:
			response = gson.fromJson(responseBody, responseClassOf);
			break;
		case 400:
			CieloRequestException exception = null;
			CieloError[] errors = gson.fromJson(responseBody, CieloError[].class);

			for (CieloError error : errors) {
				System.out.printf("%s: %s", "Cielo Error [" + error.getCode() + "]", error.getMessage());

				exception = new CieloRequestException(error.getMessage(), error, exception);
			}

			throw exception;
		case 404:
			throw new CieloRequestException("Not found", new CieloError(404, "Not found"), null);
		default:
			System.out.printf("%s: %s", "Cielo", "Unknown status: " + statusCode);
		}

		return response;
	}