Stephen Connolly stephenc

Working on this to add to EasyGloss.

There are a number of rules that JPA entities must obey:

• equals and hashCode must only be based on the persistent fields that are @Id annotated.
• annotations must be applied to either fields or getters, no mix & match (although future versions of the spec may provide for such)
• In general, getters and setters should be simple methods (i.e. no complex processing)

I want to have a JPA Entity excerciser that will check these rules for you (and can be included in your unit tests)

I have been reading a book on C# recently, and it got me thinking about Java’s hashCode() in a little bit more detail than I had before.

Consider the following Java class.

public class Person {  
	private String firstName;  
	private String surname;  

	public Person(String firstName, String surname) {    
		this.firstName = firstName;    
		this.surname = surname;  
	}  

	public boolean equals(Object other) {
		/* proper equals checking firstName and surname */  
	}  

	public int hashCode() {
		int code = surname.hashCode();
		code = 31 * code + firstName.hashCode();    
		return code; 
	}  

	public String getFirstName() { /* getter */ }  
	public void setFirstName(String firstName) { /* setter */ } 
	public String getSurname() { /* getter */ } 
	public void setSurname(String surname) { /* setter */ }
}

What is wrong with the above? Ignore that the hash code may not be well designed given that names are usually A-Z only and the prime factor may not be the most efficient algorithm for calculating hash codes for our data set.

Let’s have a look at some em.merge related fun.

From discussions on a number of forums, here is my explanation for what goes on when you call em.merge.

We will use the following classes as an example:

@Entity
public class Parent {
    // ...
    private List<Child> children;
    // ...    
    public List<Child> getChildren() { return this.children; }
    public void setChildren(List<Child> children) { this.children = children; }
    // ...
}

@Entity
public class Child {
    // ...    
    private Parent parent;    
    // ...    
    public Parent getParent() { return this.parent; }    
    public void setParent(Parent parent) { this.parent = parent; }    
    // ...
}

To aid in understanding, we will assume that our client has a UserTransaction ut (this is to allow us to force entity instances to become detached. Entity instances can becomedetached without using a UserTransaction, however, we want to show what happens to the entities;

Borys Burnayev has an interesting article with some useful ideas on testing annotated entities and EJB3 classes requiring injection to work.

http://www-128.ibm.com/developerworks/java/library/j-ejb3jpa.html

EasyGloss has been accepted as an incubator project on dev.java.net https://easygloss.dev.java.net/

I ran into some fun while trying to unit test my annotated entities as some of the annotations were on private fields.

Rather than create constructors to do the injection for me, or change the access type on the fields, I came up with this little framework that people might be interested in. (Or be able to help improve)

Temporary home: http://www.stvconsultants.com/community/easygloss/

Permanent home: hopefully on dev.java.net

Has anyone any comments?

Here are my initial thoughts (which I posted as a forum comment elsewhere)

Layer 0. Test the entity beans are deployable (You’ll need some of the framework from Layer 4 for this). Basically, you need to know that all your annotations work. Things to watch out for are multiple @Id fields in one class or @EmbeddedID or @IdClass in conjunction with @ManyToOne, @ManyToMany, @OneToMany, @OneToOne and fun with @JoinTable, @JoinColumn and @JoinColumns. Once you know how these are supposed to work with the specification, it’s not too bad to write it correctly each time. But there are some gotchas that will break things later on.

From the spec:

The deployment tool must first read the Java EE application deployment descriptor from the application .ear file (META-INF/application.xml). If the deployment descriptor is present, it fully specifies the modules included in the application. If no deployment descriptor is present, the deployment tool uses the following rules to determine the modules included in the application.

It would be nice if glassfish gave some warning that your application.xml might not be completely specified!

I have been going nuts trying to trace problems with deployment ofenterprise applications and resource injection.
I think the issue is around the application.xml file in a .ear! Without an application.xml file, everything is fine and dandy. As soon as you add an application.xml file, things start breaking… it seems that when you have defined an application.xml file only those modules that are defined in the application.xml file are loaded. Without an application.xml file, all the .jar files are scanned for @Stateless and @Statefull annotations and the modules are inferred. It would help if there was some notification that maybe your application.xml file was incomplete, or else some way of restoring the scanning behaviour if you want it. Now to go digging through the spec to see if I’m just stupidly missing something or if I need to file a bug report.

ELResolvers are where you get to extend the new unified EL for your own pages. They are not that difficult to extend, it’s just a case of:

1. Have your class extend from ELResolver
2. Implement the abstract methods
3. Add an <el-resolver> element to your <application> section in faces-config.xml
4. Start using your resolver!

OK, so why would you want to do this? Well, for one it can make some things a lot easier. I was driven to find this solution in order to dynamically generate h:dataTables with variable numbers of columns. Ordinarily you would need to bind the h:dataTable to a backing bean and have the backing bean add in the extra columns, but with c:forEach now being compatible with JSF, we have an alternative.