GWT to lighttpd/apache to glassfish 502 proxy or 500 internal errors fix

I’ve been dealing with this for a while now trying to figure out why, when using my online accounting software, users sporadically get a StatusCodeException when sending requests to the server.  I finally this week figured out what was going on; glassfish was dropping the connection or sending bad responses occasionally because it doesn’t behave in the was that the mod_proxy modules of these webservers expect it to.

Originally I was running lighttpd and I was thinking this might be a bug in lighttpd, so I eventually switched to apache.  Once I was running apache I got a much more verbose error – instead of just a plan 500 or 502 status code I got a message.  I googled that error message plus glassfish and found the solution.

I thought I’d share it here so that future searchers who are using lighttpd or apache will have more places to find the answer.

To fix the issue, add:

SetEnv force-proxy-request-1.0 1

SetEnv proxy-nokeepalive 1

To your apache httpd.conf.  I don’t know what the equivalent fix for lighttpd is, if there is any.

From this fix, it appears that glassfish is misbehaving in some way in relation to being behind a proxy, but I don’t what way that is and I’m just glad I fixed this mysterious problem!

If any of you readers have more information about this issue, please comment!

Getting an SSL private key into glassfish

After much frustration I finally figured out how to get my existing private key and certificate into glassfish’ keystore so that it worked.  You see, I did something that the makers of java keytool never thought of – I didn’t use keytool to generate my private key!  Unfortunately, keytool doesn’t allow you to import an existing private key, you can only import the certificates (e.g. the public keys).  It took me a few hours to figure out this bit of idiocy, and kudos to this blog post for enlightening me:

Import private key and certificate into Java Key Store (JKS)

I followed his steps to convert the keys into DER format and generate a keystore file from that.  Then I used keytool’s -importkeystore command to merge that new keystore into glassfish’ keystore, and used keytool to change the key’s password to match the keystore’s password.  Fixed!

Using persistence.xml and ejb3unit

Lately the “Don’t Repeat Yourself”, or DRY, principle is quite popular. I like it quite a bit myself. However, when using ejb3unit, I found that I had to maintain two lists of persistence classes – one for ejb3unit, and one for the java persistence system. Today I finally decided to address this problem, and I haven’t regretted it!

I wrote a method which finds and parses my META-INF/persistence.xml and returns an array of classes from it. I can pass this to the constructor of the BaseSessionBeanFixture when I create the test case object.

Here it is:

 public static Class[] getDbClasses() {

        URL[] persistenceUnits;

 	try {

 		persistenceUnits = Classpath.search("META-INF/", "persistence.xml");

 	} catch (IOException e) {

 		throw new Error(e);

 	}

        Set> classes = new HashSet>();

        for (int i = 0; i < persistenceUnits.length; i++) {

            URL url = persistenceUnits[i];

    		try {

             nu.xom.Builder b = new nu.xom.Builder(false);

             Document d = b.build(url.openStream());

             Nodes unitNodes = d.getRootElement().query("//p:persistence-unit",  			new XPathContext("p", "http://java.sun.com/xml/ns/persistence"));

             for(int j=0; j < unitNodes.size(); j++) {

             	Node unitNode = unitNodes.get(j);

            	Element unitElt = ((Element)unitNode);

 		String unitName = unitElt.getAttributeValue("name");
		if(!unitName.equals("my-persistence-context"))
          		continue;

 	        Nodes classNodes = unitElt.query("//p:class",  			new XPathContext("p", "http://java.sun.com/xml/ns/persistence"));

 	        for(int k=0; k < classNodes.size(); k++) {

            		Node classNode = classNodes.get(k);

             		if(!(classNode instanceof Element))

             			continue;

         			Element classElt = (Element)classNode;

         			if(!(classElt.getLocalName().equals("class")))

         				continue;

 	            	String className = classNode.getValue();

 	                System.out.println("   class: "+className);

 	            	Class classInstance = Class.forName(className);

 	            	classes.add(classInstance);

 	            }

             }

    		} catch(Exception x) {

    			x.printStackTrace();

    			throw new Error(x);

    		}

        }

        return classes.toArray(new Class[classes.size()]);

 }

This is making use of the “Classpath” utility class from facelets, available here. Also note that you’ll have to replace “my-persistence-context” with your own persistence context name.

This also serves as an example of how to find things in the classpath and configure yourself; I’ve used for my own GWT templating system based on facelets. I used the facelets code to find my own tag libraries, just the way that facelets does. It’s quite a nice model for auto-discovery!

Eclipse J2EE Module Dependencies Page contains Illegal Values

I just ran into this problem that eclipse wouldn’t display the J2EE module dependencies for a couple of my projects.  The solution I found was to open the MANIFEST.MF files for those projects and delete the classpath entries.  I suspect I had some old classpath entries in there which were no longer valid, and the property page code was flipping out about it.

Hope this helps someone …

Glassfish: Setting the context-root of a WAR inside an EAR

I’ve been bashing my head against THIS one for weeks, on and off.  Each time I tried to figure out how to map my app to the name of my choice (‘/’) nothing I did seemed to work!

Finally today I learned about yet another XML file you have to edit in Java EE – application.xml.  Yep, the Java EE development life is filled with wonderful and magical XML files.

Application.xml is a lot like web.xml, but it applies to the EAR.  What isn’t obvious, and which nobody warned me about, is that the context-root for an app is set in application.xml, and it doesn’t matter what you put into sun-web.xml, web.xml, or anything else to try and rename the context-root of your war.  application.xml will override all of that.

So, I’m happy to have found it, but sad that it took so long.  Hopefully others having the same problem – “context-root in sun-web.xml ignored” or “glassfish ignores my context-root” for those searchers out there – can find this post and be enlightened by it!

Database schema migration with LiquiBase

One item of concern for me during development is figuring out what to do one I have actual live data on a database, and I can’t do schema updates by dropping all tables and letting hibernate re-create them.

A solution I’ve run into today that seems promising is LiquiBase. It’s still very much in development but they are working on roughly what I want.

The idea behind liquibase is fairly simple – store a list of database changes to a file, and let the user run them. I think it has a way to keep track of which changes were already run in the past, and then it can roll forward any new changesets you add to the file. This is a great idea!

The only trouble I have with it is that I’m using hibernate to generate my database schemas and I’m generally pretending I don’t know anything about the schemas it generates (sequences, foreign keys, foreign key names, not null constraints etc.). LiquiBase generally assumes you know what changes are being made and you’ll be entering them into the changesets file as you go.

LiquiBase does provide a diff tool which allows me to generate XML changesets that would convert one schema to another. I should be able to take that XML diff and “fix it up” to replace drop/create with a rename, or provide a custom data upgrader.

The last bit is one thing that seems promising. I can specify a Java class which is instantiated and used to roll forward or back a changeset. I think this will be something I’d use to manage the “real” schema changes – adding new relationships. Without something like this, there’s no way for me to transform the data properly. So, I can tweak the changesets to prepare my data upgrade, then have it invoke my class, then finish the job. Probably it’ll create new columns and remove constraints first, then run my custom code, then drop columns and add constraints afterwards.

So, a tool with promise. I haven’t managed to use it yet, unfortunately. I’m putting all my tables into a seperate postgres schema and the schema support is temporarily incomplete, which means I’d have to do a bunch of messing around to get it to work easily for me. Once I get closer to the point of really needing it, hopefully that’ll be fixed or I can copy the tables into the public schema temporarily for diffing purposes in order to figure out what hibernate changed.

Ideally there would be a tool I could use to take an existing changeset file and persistence unit (persistence.xml and a bunch of annotated classes) and generate the changes I could put into the LiquiBase changeset file (after fixing up anything not automatically handled by the diffing tool). That way, just before I make a “release” to production, I would run that tool and it would do its magic.

I can think of a way to do that manually now – I could create a temporary database using the old XML, and another temporary database with the hibernate classes, and diff them. Currently my ejb3unit test cases leave behind the latest hibernate-generated database, so I just need a copy of the last released database to do my diff. Then, I drop that into my XML file and my next deploy should upgrade the database automatically. I’d also have to turn off the hibernate’s schema update and only use this scheme to manage the database being used in Java EE, both in development and production, but that’s a good thing since it’ll mean I’m testing the schema changesets during development.

Still, this schema issue is a bit of a pain to work around, so I’ll wait a bit and see if I can get a fix for that before I spend any more time on this.

Hibernate + fetch=FetchType.LAZY making trouble

Now, for the third time, I’ve run into some weird and wonderful situation where a lazy object wasn’t initialized when I was using it.  When will I learn?  Don’t use FetchType.LAZY unless you’re really know what you’re doing, and test carefully afterwards.  The precise problem I seem to be having is that my hashCode() and equals() methods don’t work.  Anyway, a word of caution!

The seductions of hibernate specific features and annotations

I recently did a bit of exploration, experimenting with different JPA (Java Persistence API) implements to see which one would work best for me. Initially this was triggered by some frustrating behavior on the part of Toplink Essentials’ JPA implementation. Next, I tried OpenJPA, because I read a blog post by someone who seemed to find OpenJPA a refreshing change. OpenJPA had somewhat better error messages much of the time, and did some helpful validation, which was nice. However, I found that OpenJPA was missing some features that I was using, and for whatever reason (maybe my own cluelessness) I eventually ended up in confusing error message hell anyway. Then I tried hibernate, but I soon found myself unhappy with Hibernate as well and switched back to Toplink.

Now, however, I’ve switched back to hibernate again. Why?

• ejb3unit uses hibernate internally, and using a different JPA provider from my unit tests makes the tests less valuable.
• Hibernate Annotations: I want to be able to “remove” an object without removing its row from the database; this allows me to keep old objects around for “undo” and history/auditing purposes. I was afraid that I would have to replace all my collections with queries in order to achieve this effect, in which case the whole point of using ORM seems to be negated. Hibernate provides a @Where annotation on a collection which achieves this effect really nicely. Once I used that feature once, I found a ton of other places where I can use it.
• Hibernate Search: Hibernate comes with a really nice search system; the only alternative I’ve seen is Compass, which also looks nice but I seem to the find the hibernate documentation a bit easier to get started with. Hibernate Search only works with hiberate as the persistence provider, so that’s another reason to use hibernate.

Hibernate does have it’s disadvantages; the largest in my mind is the unfortunate support situation. It seems like hibernate has become “too popular” for its maintainers to handle, and the conversion rate from user to maintainer isn’t very good. As a result their forums and issue tracker are littered with agressive push-back against the users, trying to get them to read all kinds of documentation and forum posts before posting any issues, and they want every issue posted to be carefully constructed and including a test case. A bit much to ask, in my opinion. If the product were simply easier to use, and helped the users more, they’d have a lot less issues.

I think if hibernate were to provide better validation and error messages that guide users to the problem more rapidly, there’d be much less traffic on the hibernate forums and issue tracker.

Anyway, that’s where I am in my JPA & Java EE adventures.

Fix Toplink Essentials and OpenJPA by switching to Hibernate?

My journey through the land of Java Persistence API implementations continues. Originally, I used TopLink, because that’s what came with Glassfish, and someone told me I should use Glassfish and I believed them.

However, TopLink’s error messages run the full gamut from useless to confusing to misleading. For example, if an Entity class is a subclass of a class defined in a jar that’s not in the same war, you get a ClassNotFoundException that doesn’t tell you what class it was looking for, what class it was trying to load, or anything else of use, really. This is only one example, debugging toplink errors is all about screwing around until it starts working again.

Then I tried OpenJPA, as mentioned in my previous post. Unfortunately, OpenJPA doesn’t support all the features I’m using, like a collection that’s a Map where the key is an Entity class and a field in the target object. Or something – I didn’t delve far enough into this to figure it out, but changing that to a list and doing my own linear search seemed to fix THAT issue, but it was only the first thing that OpenJPA choked on. OpenJPA’s error messages were much better than TopLink’s, but it was lacking in features.

Now I’m trying Hibernate. However, hibernate wouldn’t let me put FetchType.EAGER onto collections inside my entities. Apparently for the Hibernate folks, FetchType.EAGER means it must be done in the same SELECT query, so fetching multiple collections returns a number of rows equaling the product of the number of rows in all those collections. I guess they forgot that you can actually do multiple queries in rapid succession and then pick up the results seperately. That would be too user-friendly for a JPA implementation, and violate the secret code of JPA implementors (that secret code being: if you haven’t worked on the source code for our implementation for at least a month, screw you!). Hibernate certainly doesn’t earn a gold star in error reporting – for the getters lacking annotations it just gave me a column name (no class name) so I had to go searching around since many of my classes have same-named columns. For the FetchType.EAGER problem, it didn’t give me a class name, column name, or even a suggested solution! Luckily google indexes their forums and I did manage to sort these issues out with a bunch of searching online and in the source code.

So …. the question mark remains on the end of the subject because I can’t really say whether Hibernate is going to be an improvement over TopLink Essentials and OpenJPA or not. Maybe after this I’ll be qualified to launch some kind of “Best of the worst: a JPA implementation comparison” website where I can compare JPA implementations for people’s benefit. Or maybe I have better things to do …

Fix toplink by switching to OpenJPA … ?

I recently ran into a post where someone said they were dropping TopLikn Essentials in favor of OpenJPA. At the time I was searching for some assistance in fixing some rather impossible to diagnose (mostly due to toplink’s incomprehensible stack traces) ClassNotFoundException. I eventually figured out that toplink’s class loader was broken in some way which I couldn’t fix, and that meant I couldn’t have my entity classes subclass something from some other jar. Or whatever, I haven’t fully diagnosed the problem, and instead decided to spend my time on getting OpenJPA installed.

This turned out to be quite easy – I just downloaded the openjpa binaries and copy the openjpa jar and lib/*.jar from that disitribution into glassfish/domains/domain1/lib, then changed my persistence.xml to specify OpenJPA as the persistence provider:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="db">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>db</jta-data-source>
...


Even though OpenJPA is more strict about not using field accesses when using property-mode fields (even inside the same class, you can’t use this.x) I’m so happy that it told me this with wonderfully clear error messages, it seems worth the effort to fix my code (by right-clicking a lot and picking Refactor > Encapsulate Field).

Thanks go to Sahoo for showing me how to do this:

http://weblogs.java.net/blog/ss141213/archive/2006/07/using_openjpa_a.html