Once the RequestRegistry is set, you can retrieve the settings by using its static method directly: Example:

String dataContext = RequestRegistry.getDataContext();
log.info(“Current Thread’s Data Context is” + “ dataContext);

Another Example:

User u = RequestRegistry.getUser();
log.info(“Current User: “ + u.toString());

Sometimes you want created objects to have superuser permissions or impersonate another user for security reasons. RequestRegistry has a stack-based method of doing this, much in the way that Unix shells have the su command followed by exit to leave: Example:

//Eleveate to Super User Status
RequestRegistry.superUser(SuperUser.SUPER_USER);
MyDBObject dbobj = new MyDBObject();  

//Will print out the super user id (-1)
System.out.println(“Current user is: “ + dbobj.getRequestingUid());  

//Sets the thread default user to admin.
RequestRegistry.superUser(User.getAdmin(RequestRegistry.getDataContext()));
MyDBObject dbobj2 = new MyDBObject();

//Will print out Admin’s uid [usually 3]
System.out.println(“DBObj2 User is: “ + dbobj2.getRequestingUid());

//Back out:  
RequestRegistry.revertUser();

//Will print out Super User
System.out.println(“Current user is: “ + RequestRegistry.getUser().toString());

//Revert again
RequestRegistry.revertUser();

//Will print whatever we were before calling superUser()
System.out.println(“Current user is: “ + RequestRegistry.getUser().toString());

For security reasons, always surround your superUser with try/finally blocks to ensure proper reverting to previous credentials. Expresso sets new credentials with each request to limit damage if you forget, but it is still a good practice.

try {
	RequestRegistry.superUser(SuperUser.SUPER_USER);
	//.... Do Stuff
} finally {
	RequestRegistry.revertUser();
}

Because of ramifications, we don’t make it easy to destroy the request registry settings. But it is possible. It’s a two step process: Create a new MutableRequestRegistry() and then destroy it. This is how you do it in a nutshell:

MutableRequestRegistry registry = new MutableRequestRegistry(“default”,SuperUser.SUPER_USER);
registry.releaseSettings();

You may recall how it was stated that the RequestRegistry uses ThreadLocal variables to set its data. Well, that becomes a problem if you spawn a new thread: All ThreadLocal variables won’t automatically transfer over there. There are two ways of doing this: slightly manual and fully automatic. Both ways center around the class com.jcorporate.expresso.core.registry.ExpressoThreadContext . This class copies the RequestRegistry settings when it is created, and applies them to the thread that calls applyToCurrentThread(), thus creating a stable RequestRegistry for the new thread.

Example: Thread 1:

ExpressoThreadContext context = new ExpressoThreadContext();
MyThread t = new MyThread();
t.setContext(context);
t.start();
....

Inside MyThread:

public void run() {
 	this.getContext().applyToCurrentThread(). //Creates a new RequestRegistry for us.
	......
}

Of course, this is acutlly a bit of a bother, so Expresso provides the com.jcorporate.expresso.core.registry.ExpressoThread class to do this for us. All we have to do is make sure that inside our run() method, we call super.run() .

Example:

class MyThread extends ExpressoThread {
	public MyThread() {
		super();
	}
	
	public void run() {
		super.run();
		//Do the rest of your stuff.
	}
}

The client only needs to treat your object normally:

Thread myThread = new MyThread();
myThread.start();

All the manual RequestRegistry transfer is taken care of for us.

Whenever you create a new program, make sure you call new MutableRequestRegistry(“default”, ...); to set the default request registry as soon as ConfigManager is done initializing. If your program has no concept of security then

new MutableRequestRegistry(“default”,SuperUser.SUPER_USER);

will suffice.