Search code examples
javajbossejbwildfly

How to send some information about caller/client to server side using Remote EJB on Wildfly?


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 ?


Solution

  • 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 (e.g. with server2server calls, bean2bean calls on local asynch EJBs, ...) complexity increases. Don't forget to think about cleaning up e.g. your ThreadLocal data to avoid possible memory leaks.