I'm looking for a better understanding of EJBContext in order to solve a design problem I have.
All of our database tables have 4 common fields in them: ADDED_DATE, ADDED_BY_ID, UPDATED_DATE, and UPDATED_BY_ID. This is a standard that the DBA's have settled on in order to have a useful level of audit information in the database. Basically, for each row of data, you can tell who caused the row to be added and who last caused it to be updated.
Now, the system I'm developing has about 12 entity beans that are being CMP'ed to our database. I can easily set the ADDED_DATE and UPDATED_DATE fields by basically having the entity bean get a timestamp whenever it is created/updated. The problem has to do with the ADDED_BY_ID and UPDATED_BY_ID fields. Whenever a new entity is created or is updated, I don't know how to determine who the user was that initiated the create/update on the web tier. One solution is to have the user ID passed in by the application controller session bean. This means having to add "userID" to every possible setter and create methods. This is a very messy solution and goes against the general design pattern for setters.
How do I resolve this situation? Can I use the EJBContext somehow to solve this? I know that it has a getPrincipal() method but I don't think it is really going to give me the user that is logged in to the app. How do I tie the web's session context and the EJB context together to have the correct user ID available when I'm inside my entity bean's setter?
You get the current user name by calling ctx.getCallerPrincipal().getName(), where ctx in the entity or session context provided by the container through the appropriate set method.
Note that your beans will only be given the proper security/user information if you have enabled security for them (i.e., assigned roles and mappings). Otherwise, you may just get 'guest' back for the username (the EJB spec guarantees that getCallerPrincipal() will not return null).
How does the principal that I get back get initialized?
Let me know if the following scenario is true:
1.The client (web tier or desktop app) creates its InitialContext with a specific user name.
2.The client looks up its stateful session bean controller using this context.
3.At this point, does the session bean's context include the user name specified by the client? If so, the session bean can use this context to lookup entity beans.
4.At this point, does the entity bean's context include the user name originally specified by the client? If so, then on an update the entity bean can get the user name from the context.
What you stated should be true as long as during step (1) the container performs user authentication and security has been setup on your bean.
Isn't the user info going to relate to the web server user? My understanding is that what Julian's after is the user who has (I assume) logged into the stateful session bean... Unless each user connects to the app server with their own username it wont work will it???
The role(principal/user) are defined at the App Server/Container level, not Web server level.