最後に、以前の回答と私の個人的な調査に基づいて、次の解決策を保持しました。
サーバー障害の管理専用のインターセプターを作成しました。
public class FaultBarrierInterceptor {
@AroundInvoke
public Object intercept(final InvocationContext invocationContext) throws Exception {
try {
return invocationContext.proceed();
} catch (final RuntimeException e) {
final Logger logger = Logger.getLogger(invocationContext.getMethod().getDeclaringClass());
logger.error("A fault occured during service invocation:" +
"\n-METHOD: " + invocationContext.getMethod() +
"\n-PARAMS: " + Arrays.toString(invocationContext.getParameters()), e);
throw new TechnicalException();
}
}}
スローされた技術的例外は EJBException を拡張し、RuntimeException の原因を明らかにしません。
public class TechnicalException extends EJBException {}
私はすべての公共サービスでこのインターセプターを使用しています:
@Stateless
@Interceptors({FaultBarrierInterceptor.class})
public class ShoppingCardServicesBean implements ShoppingCardServices { ...
これはFault Barrier パターンの実装です。
TechnicalException を使用して、すべての実行時例外がキャッチされ、ログに記録され、エラーが (内部の詳細なしで) クライアントに通知されます。チェック例外は無視されます。
RuntimeException の処理は一元化され、ビジネス メソッドから分離されています。