Auditing in J2EE : How to pass the username from a remote client to the EJB container

Context:
I need to audit changes in my business entities, setting the username in a userLog field.

And I don't want to mix the auditing data and the business data.
I mean, I don't wan't to pass the user (or username) as a parameter of my business method just because it is needed for audit purpose.

Solution:
In this case, the simplest way is to pass this metadata during the JNDI lookup.
The EJB container will create a security context for my invocation with the received username.
Then, every EJB would obtain the principal (and thus, the username of the authenticated user in the remote client context) with a simple EJBContext.getCallerPrincipal().

Here is a simple example with JBoss:

In the client: Properties props = new Properties(); props.put(Context.PROVIDER_URL, "jnp://localhost:1099"); props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory"); props.put(Context.SECURITY_PRINCIPAL, principal.getName()); this.initialContext = new InitialContext(props); ... this.initialContext.lookup("ejb/MyService");
In my entity: @PrePersist protected void setUserLogAndDateLog() { try { InitialContext ic = new InitialContext(); SessionContext sctxLookup = (SessionContext) ic.lookup("java:comp/EJBContext"); Principal principal = sctxLookup.getCallerPrincipal(); if (principal==null) { throw new IllegalStateException("Principal is not set"); } this.setUserLog(principal.getName()); this.setDateLog(new Date()); } catch (NamingException ex) { throw new IllegalStateException(ex); } }
Restrictions:
In order to reduce the lookups to Stateless EJB, the lookup can be done only once and the proxy can be kept in a cache (having a Business Delegate as Singleton, for example).
If we want to pass the username with the JNDI invocation, we have to maintain an instance of the Business Delegate for user.

Why Threadlocal musn't be used with EJB...

There is nothing in the EJB specifications that prohibits the use of ThreadLocal.
It only says in the Programming Restrictions (21.1.2):

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

But nor does the EJB specifications ensure that all local invocations in the EJB container will run in the same thread.

Generally application servers use a single thread for local invocations: I have tested it on OC4J and JBoss.
But I think it's really dangerous to rely on this feature as it can change without warning.

So, my recommendation is "Dont't use ThreadLocal with EJB" !

Web Service Client in a J2EE application, using JAX-WS

In my J2EE application, I use an external web service. I have generated a client of this WS using the JAX-WS tool wsimport. Constraints:

• This web service won’t always be up.
• As my web service client has been generated from the WSDL, I do not want each invocation of the web service to go over the network to accesses the WSDL.
• The URL of the WS must be obtained from the configuration.

Use of the WS client in an EJB 3.0 I use the standard J2EE 5.0 dependency injection: @WebServiceRef private MyWSService myWSService; Use of a local copy of the WSDL The WSDL I used to generate the client is copied in the client’s package. The static constructor of the client is then changed to this: static { URL url = null; url = webservice.client. MyWSService.class.getResource("/webservice/client/MyWSService.wsdl"); WSDL_LOCATION = url; } This solution is suggested on this post. I tried to use OASIS catalogs but it seems that they are not supported by JBoss 4.2.2.GA. I tried another solution proposed here. The example 2.11.3 doesn’t work because the following line of code generates a “Malformed URL” exception: url = new URL(baseUrl, "../Soap11MtomUtf8.svc.xml"); Change of the target WebService URL at runtime MyWS myWS = myWSService.getMyWSPort(); ((BindingProvider) myWS).getRequestContext().put( BindingProvider.ENDPOINT_ADDRESS_PROPERTY,getURL()); response = myWS.sayHello();

System Quality Attribute

From the SAF Framework:

• End User’s view
• Performance
• Availability
• Usability
• Security
• Developer’s view
• Maintainability
• Portability
• Reusability
• Testability
• Business Community view
• Time To Market
• Cost and Benefits
• Projected life time
• Targeted Market
• Integration with Legacy System
• Roll back Schedule

See ISO/IEC 9126-2001 Information Technology – Software Product Quality

A simple code revison for a JSF / EJB3.0 project

In my current J2EE project (JSF with EJB 3.0) , we did a simple code revision. The points of verification were:

• Presentation tier (JSF)
1. JSP mustn’t contain Java scriptlets.
2. JSP must contain references to backing beans via JSF binding.
3. Catalogs must be cached in a bean with scope “application”.
4. Backing beans must use the Business Delegate in order to communicate with the business tier.
5. When a Business Delegates helper invokes a Stateless Session Bean, the Business Delegates helper can be a singleton and the lookup can be done in the constructor. This way, there is only one Proxy and one JNDI lookup.
• Business tier (EJB 3.0)
1. There must be only one invocation to the business tier per request (with this restriction, we try to ensure that EJB services are coarse-grained business components).
2. All the database access must be delegated to DAO classes.
3. DAO mustn’t contain business logic.

It helped a lot :)