Bordello - Poor man's dependency injection

What do you do when there is no Spring or other facility to handle dependency injection? How do you fake services in your unit tests?

One way is to use Bordello to instantiate services in the application code. It is not dependency injection per se but it lets you test.

	import java.util.concurrent.ConcurrentHashMap;
	import java.util.concurrent.ConcurrentMap;
	/**
	* Service Locator Pattern - Dependency Injection by any other name.
	* Allows unit tests to set a mock instance for some interface or class.
	*
	* <pre> SomeClass instance = Bordello.get(SomeClass.class); </pre>
	*
	* Requires simple constructor. Interfaces declare the implementing class. <pre>
	* {@code @}Implementor(SomeTingImpl.class)
	* public interface SomeTing {
	* ...
	* </pre>
	*/
	public class Bordello {
	// ConcurrentMap handles multi-threading and the Double-Check Locking problem.
	private final static ConcurrentMap<Class<?>, Object> services = new ConcurrentHashMap<Class<?>, Object>();
	/**
	* Acquire an implementation of a service. If one has not already
	* been instantiated, instantiate the class defined by the
	* Implementor annotation on the interface
	*/
	public static <T> T get(Class<T> interfaceClass) {
	Object service = services.get(interfaceClass);
	if (service != null) {
	return interfaceClass.cast(service);
	}
	// service does not yet exist
	try {
	Implementor annote = interfaceClass.getAnnotation(Implementor.class);
	Class<?> implementingClass;
	if (annote != null) {
	implementingClass = annote.value();
	} else {
	implementingClass = interfaceClass;
	}
	Object newservice = implementingClass.newInstance();
	service = services.putIfAbsent(interfaceClass, newservice);
	if (service == null) {
	// put succeeded, use new value
	service = newservice;
	}
	} catch (Exception e) {
	throw new RuntimeException(e);
	}
	return interfaceClass.cast(service);
	}
	/**
	* Set an alternate service implementation.
	* Typically only called in unit tests.
	*/
	public static <T> void set(Class<T> interfaceClass, T providor) {
	synchronized (interfaceClass) {
	services.put(interfaceClass, providor);
	}
	}
	/**
	* Clear all previous instances - use before setting up for a unit test.
	*/
	public static void reset() {
	services.clear();
	}
	}

view raw bordello.java hosted with ❤ by GitHub

This is a variation on www.artima.com/weblogs/viewpost.jsp?thread=238562 that handles concurrency correctly.

RESTful POST Once Exactly (POE) variation

How do you control form POSTs from the client (browser) to the server to prevent a double-submit from being processed twice on the server?

Client : POST "/widget/" Expect: 100-continue []
Server : write new transaction id to db
Server response : 100 Continue, POE: {tranid}
Client : POST "/widget/" POE: {tranid} [body]
Server : POE {tranid} exist in db?
Server : delete {tranid}
Server : Create new resource from [body].
Server response : 201 Created, Location: {newuri} [body]
Client : ...

Reference: http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt

Hibernate Entity equals - id or others

The Hibernate entity object represents a database table and the Java equals(Object o) method determines identity among entities for a given table.

Hibernate itself identifies rows from a table by their primary keys, following the principles of relational theory as developed by Edgar Codd in the 1960s. Today the id is typically generated automatically by Hibernate and the database engine.

	@Entity
	@Table(name = "MY_TABLE")
	public class MyTable extends AbstractEntity {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private Long id;
	private String value1;
	private String value2;
	...
	public boolean equals(Object obj) {
	if (obj == null || !(obj.getClass().equals(this.getClass()))) {
	return false;
	}
	return getId().equals(((GenericEntity ) obj).getId());
	}
	}

view raw hibernate-entity-equals.java hosted with ❤ by GitHub

A new theory says that an entity's equals method should not compare ids but should compare all attributes other than the id, i.e. value1 and value2 in the example above.

Arguments FOR comparing attributes other than the id

• When creating new entities, the entity has no id assigned before it is saved to database, so the id cannot be used to determine identity.
• It is the various attribute values, not the id, that make up the significance of any row of data.

Q. Would it not be inefficient to compare all the attributes rather than the id?
A. Differences would typically be encountered fairly rapidly making the additional processing negligible.

Arguments AGAINST comparing attributes other than the id

• Hibernate lazy initialization can be triggered by a comparison after the Hibernate session has ended. Scenarios include cached entities.
• Regardless of identical attribute values, if the ids are different then there are separate rows in the database.
• The comparing of ids parallels relational theory, a central principle for all relational databases, also paralleled by Hibernate.

Bottom line

The Hibernate entity equals method should compare IDs.

PHP Love/Hate - Inheritance Depth

Just made the discovery that class inheritance has its limits in PHP. It took several days of pain to discover this, due to the fact that my hosting server (5.1.6) does not run exactly the same version as my dev environment (5.2.5), and the particular transaction I was testing is initiated by PayPal.
Lesson learned:

• Single inheritance is ok
• > 1 inheritance depth fails in some versions

I guess I'm spoiled my the elegance of Java and Ruby, expect industrial strength engines. And I have to admit I am no virtuoso in my command of PHP.
Hopefully eclipse Galileo's PDT 2.1 (PHP Development Toolkit) might ease my dev pain.