Therefore, this article presents a small client application that uses both the normal OAuth 1.0 mode and the 2Legged mode (also know as “signed fetch”) for accessing a protected resource.

Before we begin with the client application, some references are in order. I will present here only the details of the protocol that are interesting for the target of this article. If one needs further information,  one should check the reference links below in order to get a good understanding of the protocol.

The following links are useful when dealing with the OAuth protocol:

• OAuth protocol homepage
• OAuth 1.0 RFC
• OAuth implementations (a list that is little bit outdated, unfortunately)
• OAuth plugin for Spring Security (since the previous OAuth article, the plugin has moved from Codehaus to SpringSource)
• Spring Security OAuth plugin wiki
• Spring Security OAuth plugin for 2Legged setup
• Sparklr and Tonr examples
• Very good thread discussing the changes to perform in Sparklr for having the 2Legged mode working

This article presents only the client code for the two modes: the normal mode and the 2Legged mode. The server that will be used is the Sparklr sample application (I decided that it makes no sense to build my own server application, since it will most likely be an almost identical copy of the Sparklr; therefore the client is custom, but the server is the one provided as sample for the Spring Security OAuth plugin).

OAuth normal mode

In the normal mode the OAuth protocol involves 3 parties: the provider of the protected resources (the server that stores the resources), the consumer of resources (the application that needs access to the resources) and the user (the human or non-human party that owns the resources).

The prerequisites are the following:

• the provider stores one or more protected resources, on behalf of the user
• the user has an account on the provider application, through which he/she/it can access the resources
• the user needs to securely allow the consumer to access the protected resources stored by the provider

The flow happens like the following:

1. the consumer issues a request for a temporary token (called the request token). For this request it needs the consumer key and the consumer secret. The request is signed using these security details.
2. the provider verifies the request and issues the request token, which is returned to the consumer.
3. the consumer sends the user to the provider’s site, in order to authorize the request token. Optionally, on the provider’s site the user will have to log in (if he/she/it is not already authenticated there). After the log in, the provider asks the user to authorize the access of the consumer on the protected resources.
4. after authorization on the provider’s site, the provider generates a request verifier, which the user must give to the consumer (this happens, in most cases, automatically by using a callback URL that the provider builds using the URL given by the consumer and the newly generated verifier; the user is then redirected to this callback URL).
5. the consumer uses the request token and the verifier to make a second request for the access token
6. the provider verifies the request and generates the access token
7. the consumer uses the access token to make a third request, this time for the actual protected resource

2Legged mode (aka signed fetch)

The 2Legged mode of the OAuth protocol is called this way becase instead of having 3 parties involved (the provider, the consumer and the user) one has only 2 parties (the provider and the consumer). The user is left outside of the game, since the cases when this mode applies simply don’t need the user. For example some mobile applications might need to access server resources that are owned bya particular user. Therefore, the OAuth protocol can be employed and the consumer will only need to know the consumer key and the consumer secret in order to be able to access the resources.

The prerequisites are the following:

• the provider stores one or more protected resources
• the consumer needs to securely access the resources, using a consumer key and a consumer secret

The flow happens like the following:

1. the consumer makes a signed request to the provider, using the consumer key and the consumer secret in order to build the signature of the request
2. the provider verifies the request and returns the protected resource

The code

The following Java class tests both modes (after this class and the Maven pom XML, there are also some small changes that one needs to perform in the Sparklr application, in order to have the 2Legged mode running, so make sure to read to the bottom of the article):

[java]
public class TestOAuthClient {

private static final Logger log = LoggerFactory.getLogger(TestOAuthClient.class);

private static final String SERVER_URL = “http://localhost:8080″;
private static final String SERVER_URL_OAUTH_REQUEST = SERVER_URL + “/oauth/request_token”;
private static final String SERVER_URL_OAUTH_CONFIRM = SERVER_URL + “/oauth/confirm_access”;
private static final String SERVER_URL_OAUTH_ACCESS = SERVER_URL + “/oauth/access_token”;

private static final String RESOURCE_URL = SERVER_URL + “/photos?format=xml”;
private static final String RESOURCE_ID = “photos”;

private static final String CONSUMER_KEY = “tonr-consumer-key”;
private static final String CONSUMER_SECRET = “SHHHHH!!!!!!!!!!”;
private static final String SIGNATURE_METHOD = “HMAC-SHA1″;
private static final String DEFAULT_ENCODING = “ISO-8859-1″;

// ————————————————————————————————-

public static void main(String[] args) throws IOException {
testClassicMode();
test2LeggedMode();
}

// ————————————————————————————————-

private static void testClassicMode() throws IOException {
OAuthConsumerSupport consumerSupport = createConsumerSupport();
// step 1 – get the request token
OAuthConsumerToken requestToken = getRequestToken(consumerSupport);
// step 2 – wait for the user to grant access on the protected resource
String verifier = authorizeRequestToken(requestToken);
// step 3 – get the access token
OAuthConsumerToken accessToken = getAccessToken(consumerSupport, requestToken, verifier);
// step 4 – get the protected resource
getProtectedResource(consumerSupport, accessToken);
}

private static void test2LeggedMode() throws IOException {
OAuthConsumerSupport consumerSupport = createConsumerSupport();
getProtectedResource(consumerSupport, new OAuthConsumerToken());
}

// ————————————————————————————————-

private static OAuthConsumerSupport createConsumerSupport() {
CoreOAuthConsumerSupport consumerSupport = new CoreOAuthConsumerSupport();
consumerSupport.setStreamHandlerFactory(new DefaultOAuthURLStreamHandlerFactory());
consumerSupport.setProtectedResourceDetailsService(new ProtectedResourceDetailsService() {
public ProtectedResourceDetails loadProtectedResourceDetailsById(String id) throws IllegalArgumentException {
SignatureSecret secret = new SharedConsumerSecret(CONSUMER_SECRET);

BaseProtectedResourceDetails result = new BaseProtectedResourceDetails();
result.setConsumerKey(CONSUMER_KEY);
result.setSharedSecret(secret);
result.setSignatureMethod(SIGNATURE_METHOD);
result.setUse10a(true); // set this to false to not require the verifier on the second step
result.setRequestTokenURL(SERVER_URL_OAUTH_REQUEST);
result.setAccessTokenURL(SERVER_URL_OAUTH_ACCESS);
return result;
}
});
return consumerSupport;
}

private static OAuthConsumerToken getRequestToken(OAuthConsumerSupport consumerSupport) {
log.info(“OAUTH: Request token: getting…”);
OAuthConsumerToken requestToken = consumerSupport.getUnauthorizedRequestToken(RESOURCE_ID, null);
log.info(“OAUTH: Request token: ” + requestToken.getValue());
log.info(“OAUTH: Request token secret: ” + requestToken.getSecret());
return requestToken;
}

private static String authorizeRequestToken(OAuthConsumerToken requestToken) {
log.info(“OAUTH: Waiting for token authorization… “);
System.out.println(“\t1. Go to: ” + SERVER_URL_OAUTH_CONFIRM + “?oauth_token=” + requestToken.getValue());
System.out.println(“\t2. Authorize the request for the protected resource (with an eventual login first)”);
System.out.println(“\t3. After authorization, copy the verifier value from the URL”);
System.out.print(“\t4. Enter the verifier here: “);
return new Scanner(System.in, DEFAULT_ENCODING).next();
}

private static OAuthConsumerToken getAccessToken(OAuthConsumerSupport consumerSupport, OAuthConsumerToken requestToken, String verifier) {
log.info(“OAUTH: Access token: getting…”);
OAuthConsumerToken accessToken = consumerSupport.getAccessToken(requestToken, verifier);
log.info(“OAUTH: Access token: ” + accessToken.getValue());
log.info(“OAUTH: Access token secret: ” + accessToken.getSecret());
return accessToken;
}

private static void getProtectedResource(OAuthConsumerSupport consumerSupport, OAuthConsumerToken accessToken) throws IOException {
log.info(“OAUTH: Getting protected resource”);
InputStream is = null;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try {
is = consumerSupport.readProtectedResource(new URL(RESOURCE_URL), accessToken, “GET”);
IOUtils.copy(is, baos);
log.info(“OAUTH: Resource : ” + new String(baos.toByteArray(), DEFAULT_ENCODING));
} finally {
IOUtils.closeQuietly(is);
IOUtils.closeQuietly(baos);
}
}
}
[/java]

The test project is a maven project, with the following pom:
[xml]

As one can see, for the 2Legged mode the client needs to simply give the consumer key and the consumer secret, and request the protected resources. No other token accessing is required.

The client for the normal mode works with the version of the Sparklr application that one can find in the git sources. However, for the 2Legged mode, some small changes are required in the Sparklr application.

First of all, we need to allow the consumer to access the protected resources without an authorized token. For this, one should open the sparklr / src / main / webapp / WEB-INF / applicationContext.xml and perform the following changes:

[xml]

key="tonr-consumer-key"
secret="SHHHHH!!!!!!!!!!"
resourceName="Your Photos"
resourceDescription="Your photos that you have uploaded to sparklr.com."
requiredToObtainAuthenticatedToken="false"
authorities="ROLE_USER"/>


[/xml]

Second, the PhotoServiceImpl class needs to be a little changed, in order to have it take into account the fact that a consumer might access the application without going through the normal login process. Therefore, change the PhotoServiceImpl.getPhotosForCurrentUser() like the following:

[java]
public Collection getPhotosForCurrentUser() {
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
if (authentication.getPrincipal() instanceof UserDetails) {
UserDetails details = (UserDetails) authentication.getPrincipal();
String username = details.getUsername();
ArrayList infos = new ArrayList();
for (PhotoInfo info : getPhotos()) {
if (username.equals(info.getUserId())) {
infos.add(info);
}
}
return infos;
} else if (authentication.getPrincipal() instanceof ConsumerDetails) {
return getPhotos();
} else {
throw new BadCredentialsException(“Bad credentials: not a username/password authentication.”);
}
}
[/java]

Epilogue

That is about it. Thanks again to all the people that commented on the previous OAuth article and that provided valuable insights on how the protocol works and what the 2Legged mode looks like. If you have any questions, please feel free to leave a comment below.

1. Testing half of the system at once

Therefore, the first problem with using Spring is that you don’t test just one class (that is, one unit). No sir, you are integrating and testing a part of your system, composed of your class under test but also the other services that this class is making use of. Even if you strive to only test your class (which is what you should do, since that is the unit test for a particular class, not for the entire system or for a particular functionality of the system) you will be forced to rely on other services, and hope that the other services will work correctly, and if your test fails, then the problem is in your class. Which brings us to the second problem.

2. When something breaks, you better be mr. Holmes

The problem nr 2 arises from the fact that your class is mixed with other services. Since it DOES use other services, this is the normal way for the class under test to work, but it is not ok for unit testing. For unit testing you need isolation. Why? Because only then you know that if a test fails, then you have a problem in either the class under test or the actual test that fails. You don’t have to search on 5 other services to make sure that the data retrieved from those services was correct and that the tests of the other services are correct (if they are correct, then at least you know that your class is the best candidate for the flaw owner). By making a change in a class and getting several tests to fail is a clear sign that your unit tests are not done in complete isolation and are depending one to another.

3. Working with test data

Preparing the test data for an unit test that is using Spring can be a pain in the ass. Since your services are processing and returning the data to the class under test, you need to know very well that kind of processing those services are doing, how should the input data look like, and you must tailor the input data so that after it gets through the processing of 5 services, it reaches your class under test in the shape that you want it. This, in most cases, involves custom test files and custom database records. A good approach to solve this problem is creating a fixed testing database content, which is used by all the tests. While this works for most cases, you will quickly find the need to throw some wild data to your class under test, just to make sure that you are also testing the limits and the special cases for the class methods (not only the happy paths). Since the setup for this wild data breaks the initial contract with static test data inserted in the database, you will have to resort to workarounds in order to reach your goal.

4. It’s only time…

With a good architecture and sound testing practices, you can make your live easier, even if you have to deal with the first 3 problems. However, what bothered us enough to decide that testing with Spring is bad was the time. Running a test was taking, in some cases, even 2 minutes to start. That is because Spring has a lot of dependencies to create, a lot of things to load and to start up, and it might take 2 minutes to setup the application context and create the instance of the class under test, until you get to see the first method executing. All in all, we found that half of the time the build system required to build our project was spent on creating and destroying Spring contexts.

Removing Spring from tests

Therefore, we decided to remove Spring from tests. We are using Mockito (we started with EasyMock but decided that Mockito’s methods and approach look better in code) to create mocks for the services that the class under test needs. Since Mockito allows you to make all the mocking and wiring through annotations, in some cases we don’t even need the @Before setup method. Moreover, with such mocks much more easier to prepare the test data. Since you only need to specify what data should be delivered to the class under test, you can focus on the class your are testing, and remove from your mind all the other services. You are effectively and efficiently testing your class in isolation.

Another nice thing with this approach is that you are forced to create your classes easy to test. Your classes will not be too coupled with other classes, because if they are then you will have a bad time writing the unit tests and you will like more and more to work with interfaces instead of concrete classes (even though Mockito and also EasyMock can create mocks for concrete classes).

Your tests will be blazingly fast, because all you have to wait for is the JVM to start. When something will break, it will surely be a problem in the class under test or the actual unit tests. You know this for sure, because everything that the class is using are mocks, and mocks do what they are told to do. They don’t have bugs outside the unit test.

Epilogue

To finish my story, we are currently in the process of removing Spring from the unit tests. Whenever we have to work on a test that has Spring, we first remove Spring from it, then we do the update that we had to do in the first place. In time, this showed that the tests are becoming simpler to read and understand (for someone looking at that test for the first time), the build time gets smaller and you also get the nice feeling of working with small unit test boxes that are completely under your control.

• no need to implement one factory for each listener. Reuse this generic factory for all the listeners
• implement the listeners as full Spring beans, with all the DI support that comes with the framework
• for each listener one needs one single line of configuration code (and the implementation of the listeners, of course)

Here is the generic listener factory:
[java]
public class GenericCacheEventListenerFactory extends CacheEventListenerFactory {

@Override
public CacheEventListener createCacheEventListener( Properties properties ) {
String beanName = properties.getProperty( “bean” );
if ( beanName == null ) {
throw new IllegalArgumentException( “The cache event listener factory must be configured with ‘bean’ ” +
“property pointing to the Spring bean to return as cache event listener” );
}

return (CacheEventListener) ApplicationContextProvider.getContext().getBean( beanName );
}
}
[/java]
As the code presents it, I am accessing the Spring context statically, using the simple pattern with the ApplicationContextProvider that I presented in a previous post. Ehcache creates an instance of the factory, and when it asks for the listener, the factory fetches the bean from the Spring application context and returns it to the cache manager.

Next step is to configure this factory in the Ehcache configuration file:
[xml]
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false"
monitoring="off">

properties="bean=myCacheEventListener"/>


[/xml]
When configuring, one must supply the name of the bean that should be returned as cache listener. If the property is not supplied, the factory will crash with an IllegalArgumentException to make the use aware of the slip.

Finally, here is the Spring application context, that defines the static application context provider, the cache manager and the actual cache listener (which is a very simple implementation of CacheEventListener) :
[xml]

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

Therefore, what I want to do is to have an up-and-running application context, and access the beans in that context from a static method. The best approach is to never have to do this. In an ideal case, all your classes are Spring beans, and therefore subjects to autowiring and dependency injection. However, from time to time you need to write a completely independent class, that needs to access some Spring beans.

The approach that I found it works quite ok is to have an ApplicationContextProvider. This class is picked by Spring as a bean, and since it implements ApplicationContextAware it will receive the application context. Once it does that, it stores the context in a static field, and then all the other non-Spring classes can get their hands on the context by calling some static getContext() method. Here is the class:

[java]
public class ApplicationContextProvider implements ApplicationContextAware {
private static ApplicationContext context;

public static ApplicationContext getContext() {
if ( context != null ) {
return context;
} else {
throw new IllegalStateException( “The Spring application context is not yet available. ” +
“The call to this method has been performed before the application context ” +
“provider was initialized” );
}
}

@Override
public void setApplicationContext( ApplicationContext applicationContext ) throws BeansException {
if ( context == null ) {
ApplicationContextProvider.context = applicationContext;
} else {
throw new IllegalStateException( “The application context provider was already initialized. ” +
“It is illegal to place try to initialize the context provider twice or create ” +
“two different beans of this type (even if the contexts are different)” );
}
}
}
[/java]

My context XML file looks like the following:
[xml]

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

[/xml]

And finally, the test classes that show how to use the ACP:
[java]
@RunWith( SpringJUnit4ClassRunner.class )
@ContextConfiguration( locations = “TestStaticAccess.xml” )
public class TestStaticAccess {
@Test
public void test() {
StaticAccess.doSmt();
}
}

class StaticAccess {
public static void doSmt() {
MessagePrinter printer = (MessagePrinter) ApplicationContextProvider.getContext().getBean( “messagePrinter” );
printer.print();
}
}
[/java]

As one can see from above, the ACP guards against trying to access the context before it was initialized (like, for example, calling the ACP from the static constructor of a class, long before the Spring context was started) and against the usage of the ACP in two different Spring contexts.

Please mind that I am not referring here to the case when you are in a servlet, for example, and want to access the Spring context. For this, you can safely use the alternative provided by Spring: WebApplicationContextUtils

Reading this got me thinking about how can I implement this in Java. I formulate the problem as it follows:  “How transparent for the user can one implement transactional code blocks?”. Please note that I don’t say “Can you…” but “How transparent…”. I believe that allowing any amount of stress for the user, you can implement anything. The question is, how transparent and easy to use can one do it.

First, let me present some sample (pseudo) code. Let’s assume that I have two accounts, implemented with 2 atomic integers. What I want to do is transfer one amount of money from one accout to the other. The code is something like this:

[java]
public static void main( String[] args ) {
boolean someCondition = false;
AtomicInteger account1 = new AtomicInteger( 25000 );
AtomicInteger account2 = new AtomicInteger( 0 );

{ // transactional block
try {
System.out.println( "Before op: " + account1 + " | " + account2 );
account1.set( account1.get() – 5000 );
account2.set( account2.get() + 5000 );
System.out.println( "After op: " + account1 + " | " + account2 );

if ( someCondition ) {
throw new NullPointerException();
}
} catch ( Exception exception ) {
// rollback
}
} // END of transactional block
System.out.println( "Finish: " + account1 + " | " + account2 );
}
[/java]

What I want is to have some helper classes so that I can mark the code block as transactional: if everything goes well, the changes performed in the block are permanent. If, however, something goes wrong (like throwing that NPE) then all the objects should be reverted to the initial state.

Therefore, I identify the following requirements to the problem:

1. the state of all the objects should be reverted to the initial state, before entering the transactional block
2. the commit/rollback should be as transparent as possible for the user
3. the solution should work equally for objects as for primitive types

Reverting the state of an object can be accomplished in two ways. First, the class of that object can be made aware of the whole transactional process, so that it implements methods like COMMIT and ROLLBACK. This way, it is the job of the object to save it’s state and restore it later, if something went wrong. This, however, invalidates the rule no. 2, because if the user has to implement COMMIT/ROLLBACK in each of the classes involved in the operations, then this is not transparent at all.

The second way is to let the classes be implemented without the knowledge of code transactions, and provide the transactional support using some external helper classes. This is what we will see in this post. We will implement some classes that the user can involve in the process, and all the classes will be completely unaware of the transactions that are started, committed or rolled back.

Implement this second method presents one big problem. Java does not allow passing the parameters by reference. In Java you pass parameters by value. Each value that you pass is copied, and in each method you work on a copy of the value. This means that you CANNOT change, in a method, the value of a variable from outside that method. This makes the rollback of variables a hard-to-accomplish task (I think you can do it by JNI + a specially crafted DLL that allows the swapping of memory contents (perhaps using JNative or some similar library; for the time being, I will exclude the JNI approach).

With these requirements in mind, here is how I solved the problem. First, the client code using my helper classes:

[java]
public static void main( String[] args ) {
AtomicInteger account1 = new AtomicInteger( 25000 );
AtomicInteger account2 = new AtomicInteger( 0 );

Transactional trans = new Transactional();
trans.put( "account1", account1 );
trans.put( "account2", account2 );

trans.execute( new Transactional.Execution() {
protected void execute() throws Exception {
AtomicInteger account1 = get( "account1" );
AtomicInteger account2 = get( "account2" );

System.out.println( "Before op: " + account1 + " | " + account2 );
account1.set( account1.get() – 5000 );
account2.set( account2.get() + 5000 );

System.out.println( "After op: " + account1 + " | " + account2 );

throw new NullPointerException();
// rollback();
}
} );

account1 = trans.get( "account1" );
account2 = trans.get( "account2" );
System.out.println( "Finish: " + account1 + " | " + account2 );
}
[/java]

The user must, first, create an instance of Transactional, place the objects that will participate in the transaction in the context, then start the transactional block. Inside, he/she must get the transactional objects and make any operations on them. Upon exiting the block, he/she must get the objects back from the context. If something goes wrong, the objects that the user gets in the end will be the original ones, with unchanged state. On the other hand, if all works well the user gets back the changed objects. The rollback is performed if some exception escapes from the block or the rollback() method is called explicitly.

If all works well, the code prints:

Before op: 25000 | 0
After op: 20000 | 5000
Finish: 20000 | 5000

If something wrong happens:

Before op: 25000 | 0
After op: 20000 | 5000
	java.lang.NullPointerException .......
Finish: 25000 | 0

The helper classes are as follows:

[java]
public class Transactional {

private Map<String, Object> mappedObjects = new HashMap<String, Object>();
private Map<String, byte[]> serializedObjects = new HashMap<String, byte[]>();
private boolean rollback = false;

public void put( String name, Object object ) {
mappedObjects.put( name, object );
serializedObjects.put( name, serializeObject( object ) );
}

@SuppressWarnings( "unchecked" )
public <T> T get( String name ) {
return (T) mappedObjects.get( name );
}

public void rollback() {
rollback = true;
}

// ————————————————————————–

public void execute( Execution exec ) {
try {
exec.transactionalParent = this;
exec.execute();
} catch ( Exception exception ) {
exception.printStackTrace();
rollback = true;
}
if ( rollback ) {
rollbackData();
}
}

private byte[] serializeObject( Object object ) {
ObjectOutputStream oos = null;
try {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
oos = new ObjectOutputStream( baos );
oos.writeObject( object );
return baos.toByteArray();
} catch ( Exception exception ) {
exception.printStackTrace();
return null;
} finally {
IOUtils.closeQuietly( oos );
}
}

private Object unserializeObject( byte[] content ) {
ObjectInputStream ois = null;
try {
ByteArrayInputStream bais = new ByteArrayInputStream( content );
ois = new ObjectInputStream( bais );
Object result = ois.readObject();
return result;
} catch ( Exception exception ) {
exception.printStackTrace();
return null;
} finally {
IOUtils.closeQuietly( ois );
}
}

private void rollbackData() {
Map<String, Object> originalMappedObjects = new HashMap<String, Object>();
for ( Entry<String, Object> mappedEntry : mappedObjects.entrySet() ) {
String key = mappedEntry.getKey();
Object originalObject = unserializeObject( serializedObjects.get( key ) );
originalMappedObjects.put( key, originalObject );
}
mappedObjects = originalMappedObjects;
}

// ————————————————————————–

protected static abstract class Execution {
private Transactional transactionalParent;

protected abstract void execute() throws Exception;

protected <T> T get( String name ) {
return transactionalParent.get( name );
}

protected void rollback() {
transactionalParent.rollback();
}
}
}
[/java]

As you can see, I am serializing all the objects upon entering the transactional blocks, store the initial state of them in a separate map, and let the block move on. If some exception is thrown or the user calls explicitly the rollback() method, then I restore the state of all the objects, and replace the map of objects with the restored one.

This solution is not so great, since the user must constantly get and push objects from/to the transactional context. However, the rollback is transparent to the code and also the objects are free from any transaction-oriented code.

Can you design something better? Perhaps using annotations and APT? Or somehow enhance the transactional objects and add the commit/rollback methods at runtime, on fly? Feel free to drop a comment on these issues.

What got me by surprise in the book is the end of the story. The book has a considerable size, and the action goes in a fast pace. However, the actual explanation for the dome (the reason why the dome is there, who or what is powering it up, why that city and not a different one, perhaps why not a more important one) as well as the end of the entire story happens very fast, in less than 50 pages. You wait the entire book for getting the explanation for it, and when you actually get it you realise it is not quite the one you expected, or the one that you considered as a possible option. Sure, the alien element of the dome is presented to the user at about 1/3 of the book, but I think everyone reading the book expects the dome to have a more earthly nature. However I consider this as a good element of the book, as I was not disappointed by the outcome of the story.

The end of the book also tends to be philosophical and get a 2nd sub-level of interpreting the events, which is something that you don’t encounter in the rest of the book. All in all, though, an excellent reading and some great times that I had with it.

Therefore, I chose to not do the Swing editing in Eclipse. I selected a different IDE, namely Netbeans, for the Swing part. Netbeans comes with a fantastic plugin for Swing programming, formerly called Matisse. Working with the plugin is really easy, you can just drag the components, arrange them how you want, and that’s it.

To connect the interface to my code, I implemented Controller classes. The only customization that I added to the Swing forms was a reference to the corresponding controller and the wiring to the controller methods in the listeners for the buttons, menus, etc.

Here is how such a Swing dialog would look like:

[java]
public class FolderDialog extends javax.swing.JDialog {
private static final long serialVersionUID = 1L;

private FolderDialogController controller;

/**
* Sets the controller to the given value. See {@link #controller} for more details.
*
* @param controller
* the new value for controller
*/
public void setController( FolderDialogController controller ) {
this.controller = controller;
}

// ———————————————————————-

/** Creates new form FolderDialog */
public FolderDialog(java.awt.Frame parent, boolean modal) {
super(parent, modal);
initComponents();
}

……..

private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_jButton2ActionPerformed
controller.handleOkClick();
}//GEN-LAST:event_jButton2ActionPerformed

……..

}
[/java]

The reference to the controller, the setter for it and the invocation of controller’s methods were the only changes that I performed in the generated code. Otherwise, all the changes were operated using Netbeans.

I found that it was quite easy to change between IDEs, not to mention that Netbeans is REALLY fast and smart at detecting changes in the project and reloading them (for example it detects the changes in the Eclipse projects, and reloads the classpath, the libraries, and various other settings).

Usually I am against the generators of code. I don’t trust them and I think that they are not able to generate the code as easy to read and as perfect as I am able to write it. Therefore, I try to avoid them as much as possible. That is why I never use JSP/JSF editors that provide drag & drop features, like those available in VS for ASP.NET. However, for Swing development I found that Netbeans was a time saver and if it hadn’t been for me to favor Eclipse, I would have developed both of the Java desktop projects in Oracle’s IDE.

Solution no. 1 (Alin, Bedretin)

[java]
public static void doSomething() {
class CheckedExceptionThrower {
CheckedExceptionThrower() throws Exception {
throw new IOException();
}
}

try {
CheckedExceptionThrower.class.newInstance();
} catch (InstantiationException e) {
} catch (IllegalAccessException e) {
}
}
[/java]

The thing to keep in mind here is that the Class.newInstance() method invokes the specified constructor (depending on the parameters spcified to the method), and if that constructor throws a checked exception, then also Class.newInstance() throws that exception, although it doesn’t declare it.

Solution no. 2 (Cristian)

[java]
public static void doSomething() {
Thread.currentThread().stop(new IOException());
}
[/java]

With this line, the current thread is forcibly stopped (don’t use this in real life; the method is deprecated anyway) and the specified exception is thrown at the point of call to stop().

Solution no. 3 (Alexandru)

[java]
public static void doSomething() {
class MyClass<T extends Throwable> {
public void throwT(Throwable t) {
new MyClass<Error>().innerThrow(t);
}

@SuppressWarnings("unchecked")
private void innerThrow(Throwable t) throws T {
throw (T) t;
}
}
MyClass<IOException> thrower = new MyClass<IOException>();
thrower.throwT(new IOException("test"));
}
[/java]

With this third solution, the generics mechanism is used to cover the fact that the actual exception object that is thrown is not an Error (which is an unchecked exception) but a checked one. An important note regarding the exception-checking mechanism is that it functions in a similar way to the generics mechanism: the check is performed at compile time, while at runtime no enforcement is performed.

Huge thanks to all who answered the first issue of the Quiz of the week.

The problems that I will post here are not completely invented by me. Most of them are actually found in other books, on the internet, in the language specs (such as JLS), in the APIs, in the code that I am working on every day. Some of them (albeit only a few) are actually invented by me, but I don’t exclude the possibility that they are already posted somewhere else. Anyway, the source of the problem is irrelevant.

The answer(s) to each problem will be posted in the next question, next week.

Since I am posting these problems, I would also love to get comments with possible solutions, ideas for improving the problem or just general remarks about the discussed problem. So feel free to join the club, and solve the issues

Here is the first issue of this series.

We have one little gold star for you:

[java]public class TestQ1 {

public static void main( String[] args ) {
try {
if ( 2 > 3 ) {
throw new IOException();
}
doSomething();
} catch ( IOException exception ) {
System.out.println( "*" );
}
}

public static void doSomething() {
//
// edit here
//
}
}
[/java]

What you need to do is write some code in the commented lines above so that the star in line 10 is printed. You are NOT allowed to change any other part of the code except the commented lines (however, you can insert as many lines as you want in that section, not just three).

However, for more specialized unit testing purposes, such as implementing parameterized tests or theories, one must use a specialized runner (Parameterized and Theories, respectively). This, of course, gets in conflict with Spring, which needs to use it’s own runner. JUnit does not support multiple runners for the same unit test (and except for the Spring runner, all the other runners are pretty excluding one another so it kind of makes sense to allow only one runner at a time).

Here is a way for implementing a unit test class that is using Theories and Spring, combined:

[java]import org.junit.Before;
import org.junit.experimental.theories.DataPoints;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestContextManager;

@RunWith( Theories.class )
@ContextConfiguration( locations = "classpath:/spring-context.xml" )
public class IndirectSpringTest {

private TestContextManager testContextManager;

@Autowired
private PointProvider provider;

@DataPoints
public static int[] inputIndexes = { 0, 1, 2 };

// ———————————————

@Before
public void setUp() throws Exception {
this.testContextManager = new TestContextManager( getClass() );
this.testContextManager.prepareTestInstance( this );
}

@Theory
public void testThatEverythingIsWell( int index ) {
String point = provider.getPoint( index );
System.out.println( "Point: " + point );
}

}
[/java]

The central point of the sample code is the usage of the TestContextManager class for loading the Spring context (this is performed only once per unit test class, not for each method) and for initializing the test object before starting the actual test. The prepareTestInstance() method makes the autowiring of the test object’s dependencies, therefore simulating the behaviour of the SpringJUnit4ClassRunner.

On a general note, keep in mind that JUnit creates a new instance of the unit test class for each test method. The order of the methods is:

1. @BeforeClass static method
2. constructor
3. @Before method
4. test method
5. @After method
6. goto 2
7. @AfterClass static method