如何使用 Wildfly 上的远程 EJB 将有关调用者/客户端的一些信息发送到服务器端？

Question

I'm working on an application with a large number of Remote EJB service methods, and I'd like to have some useful information about the client calling the methods (other than very basic information such as IP address...).

I found this question but it's a bit dated :

How can I identify the client or caller of an EJB within the request?

Is there some kind of custom client context / work area in which I could put the caller details and receive them on server side inside a thread local ?

Basically do I have another option than adding a parameter to every single method of every service ?

Answer 1

With security enabled you have the possibility to retrieve the current user. This is pretty simple, but probably won't fit all needs.

In general, there is nothing you can use out-of-the-box. Adding some custom parameter is probably the worst option.

JBoss and Wildfly are offering the possibility to use EJB client- and server-side container interceptors. Usage and implementation details depend on the version of your application server.

I implemented this by utilizing the MDC (mapped diagnostic context) of our logging framework to enhance server side logging with caller information. You can think about this like using a ThreadLocal. Of course, you need something like a caller context on the client side holding the specific information. Global remote client data (ip address, ...) can be set within the client interceptor, too.

A coarse overview what I did:

• Configure client- and server-side logging to use additional MDC data
• Enhance client side MDC with key/value data
• Client-side interceptor enxtracts the data from the MDC and puts it on the invocation context
• Server-side interceptor extracts the data from the invocation context and enhances server side MDC

This approach is working, but depending on your application complexity (eg with server2server calls, bean2bean calls on local asynch EJBs, ...) complexity increases. Don't forget to think about cleaning up eg your ThreadLocal data to avoid possible memory leaks.