For this functionality consider using an Interceptor rather than copying and pastying the solution across many beans. Unless if you have one DAO ejb (you shouldn't have an EJB DAO per entity any way).
//you can inject the session context into the bean @Resource private SessionContext sessionContext ; //then in the method you do sessionContext.getCallerPrincipal()
917161 wrote:Why can't you use a Stateful EJB? That way you don't have to change the method signatures.
I was frustrated just like you when i saw the code, i am even convinced that it is too late to ask for a functionality like auditing, such functions needs to be addressed at the design level not at this late stage. but this is the case i have now, i cannot move to stat-full EJB option, it seems that the only option that i have is to pass the user id as a parameter in methods calls but this will take a lot of time and efforts, that is why i asked for other options......
917161 wrote:Suggest to them to configure JAAS for the security module. That will not impact the existing code at all and provides a cleaner way of adding the auditing requirement.
As i told you, it is not our code, i suggested this thing before , and the company refused for performance issues
917161 wrote:But they are asking for extra work to be done anyway. Changing the EJB interfaces to add security information is much more work than configuring JAAS and picking up the credential from the server side.
Thanks a lot for your help, although i am 100% sure that they will not agree with me (they have nothing to do with technology and they will refuse any extra work) but i will.