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

August 22, 2008

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!


GWT: Using source-path to create your own JRE emulation classes

August 15, 2008

I recently ran into an issue where a class I share between GWT and server-side java code would really, really benefit from being able to accept or return a Calendar object.  However, GWT doesn’t come with a Calendar class, so the appeared to be impossible.  Or, is it?

After some digging around in the documentation I discovered that GWT provides a directive in their module XML called “super-path”.  By adding something like:

<super-path path=”gwtonly”/>

To my *.gwt.xml file, I can tell GWT to load my own emulation classes when compiling javascript; when running in hosted mode, it will use the Java implementation of these classes.

Here’s an example source tree structure for this:

  • myapp/
  • myapp/MyApp.gwt.xml
  • myapp/client/*.java
  • myapp/gwtonly/java/lang/
  • myapp/gwtonly/java/lang/

In my Calendar and GregorianCalendar I just define exactly the methods and constants that I need for the code to *compile*.  Note that I’m not planning to actually use these classes;  I could, but the implementation is so minimal it would cause confusion for future programmers who wouldn’t understand why the calendar class behaved so weirdly in client-side code.

However, now I discovered that I have errors in my code when I compile.  Huh?  In eclipse it’s happy but in GWT it says something like “package declaration should be java.lang, but it should be”.  Oh, I see, it’s really using that package as a source folder, not as a package.  So, I fix it by changing the “package” declaration at the top to “java.lang”.  Guess who is unhappy now?  eclipse!  The two compilers can’t see eye-to-eye any more.

There is a solution – eclipse has a feature called “exclusion filters”.  I open the “Java Build Path” panel for the project, find the source folder that has all of this in it, and add an “exclude” filter for myapp/gwtonly/.  Now eclipse just ignores those files; I’ve lost a lot of eclipse java features as a result, but at least it works.

All this is part of my work on simple online accounting software, if you’re a consultant, entrepreneur, virtual assistant, bookkeeper, or freelancer go check it out.

Are Dynamic Languages More Powerful? I don’t think so

March 2, 2008

Let’s say that power means “the amount of work done per unit of time.”

It could be said that development is made up of these types of work (and much more):

  • Design
  • Prototyping
  • Learning the Language
  • Writing New Code
  • Understanding Old Code
  • Refactoring
  • Debugging New Code
  • Debugging Old Code
  • Reading Other People’s Code
  • Debugging Other People’s Code
  • Making Use of Libraries
  • Making Libraries
  • Refactoring Libraries
  • Updating to Refactored Libraries

JavaScript, Python, and dynamic languages in general do well in some of these areas but not others

For example, “Writing New Code” seems to be the area of focus for advocates of dynamic languages, who see a big power gain there, and possibly in “Learning the Language”.

It seems to me, however, that Java is just as powerful as dynamic languages in the other categories, and much more powerful if you use an IDE with support for completion and refactoring.

That is to say, I can get a hell of a lot more refactoring done per unit of time in Java using Eclipse than I’ve seen in any other language.

This post was inspired this other blog post that compares using GWT to Javascript:

Can Java learn from python when it comes to library design?

January 16, 2008

When it comes to the language wars, I eventually came to realize that productivity in a language is driven first by the library that comes with the language (if any) and second by the IDE’s that are available for that language.

One thing that makes python great is that they integrate a lot of useful stuff right into the core library. Java, unfortunately, hasn’t done a great job of following this lead. For example, they don’t provide a way to encode a Base64 string by default. When I use my IDE to search for classes with the name Base64, I get a rather amusing list of re-re-implementations and copies of the same class, all because the Java library maintainers are unable or unwilling to put this common functionality into the library.

Anyway, when I saw this, I thought “Java could really learn a few things from python about having a feature rich standard library …”

All the completions of Base64 in my Java EE app

Hibernate + fetch=FetchType.LAZY making trouble

January 6, 2008

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

January 1, 2008

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.

procedural programming, ORM implementations

November 18, 2007

It recently occurred to me that, as a consequence of the way ORMs are implemented currently, I’ve been doing some procedural programming and actually finding it somewhat uncomfortable to have to do so. I think I’ve been doing OO programming for so long, I can’t handle procedural code as well any more.

Maybe you’re wondering what the hell I’m talking about with this “ORMs are making code procedural” idea. It certainly seems like OO code – you have classes and methods and stuff, objects, etc.? Yes, it’s mostly procedural. However, I’ve noticed in both Elixir (a python framework) and the Java Persistence API that when you manage relationships between objects using an ORM, you typically use a centralized object (often called the DAO in Java-land) that persists new objects and removes old objects, as well as ensuring that both sides of the relation are always kept in sync. Although I always start out trying to put all the logic onto the objects (where, theoretically, it belongs) I always run into trouble doing this, and it’s back to using the DAO for pretty much every operation except updating simple fields.

I seem to be forgetting, for the moment, the exact reasons why this is. I know that the first problem I’ve run into has to do with the lack of delete-orphan support in the Java Persistence API. Since rows are not automatically deleted when you remove them from a collection, you need a pointer to the EntityManager when you remove from a relationship. I think I’ve run into other problems, but the details are eluding me temporarily. I’m sure there’s something I’m missing and there’s really a great way around all this, but I don’t know what it is. Maybe the next version of JPA will suck a bit less.