Apache, mod_proxy_ajp, Tomcat, SSLpache, mod_proxy_ajp, Tomcat, SSL

Just because I had to fight with it today and did not find the solution spelled out elsewhere (I found all parts, but not the definitive answer):

If you have an apache server that uses modproxyajp to proxy requests to tomcat and you want to use https as schema, even when you do redirects, you have to massage the ajp connector settings of tomcats server.xml.

Only when you add the following attributes to the connector, a redirect (for example a Spring RedirectView) will stay in https and not jump to http:

• scheme=”https”
• secure=”true”
• proxyPort=”443”

The scure attribute might not really be necessary, but it did no harm.

This is actually from Robin Johnson, but he did not mention the connector it has to be on.

If you think about it, it’s clear that it has to be the ajp connector, since apache is using that one to talk to tomcat.

Well, took me some nerves to get this into production today, so I thought I mention it, maybe it will help someone else. For me, I hope I won’t have to deal with tomact and jsp anymore…

Large Scale JSF Projects Revisited

Seven months ago I asked the question Who has done large scale JSF projects?. Now Alain O’Dea took the time to answer those questions and shares his experience with a large JSF project. Since his comment provides very useful and interesting information, I thought I do a fresh post that links directly to his comment:

Alain O’Dea on his large scale JSF project

Chiming in: JSP - Innocence Lost

Yesterday Angsuman Chakraborty wrote about his feelings concering JSP.

I totally agree with him. 7 to 8 years ago I was on several projects which used JSP. These projects ranged from one month with 2 developers to 1 year with 10+ developers. And they actually were fun to do.

Starting this year I was (and still am) involved in two projects which again used Java technology for the web frontend.

The first was using JSF. No real support for POST says all.

The current project is using plain JSP with Spring. I admit that Spring is a lot easier than EJB 2.1, but for me it still goes tha Java framework way of making difficult things possible but at the same time making easy, “default” behavior difficult.

Expression Language is something which was introduced to Java web development which I wouldn’t want to miss. But the whole setup of a JSP project using the current stack is, imho, too difficult. When Angsuman says that the current JSP technology is not usable for rapid prototyping he is right. I guess it will take most programmers between two days to a week to set up the infrastructure and build support for an JSP project.

OK, if you use tools for RAD, you might be faster, but I always like to know what is getting generated, just in case that it might not work as it should (which will happen, that is sure).

When the customer is not forcing me to use java for a web application, I would never use it. But then I guess I really have already departed.

Less Code

It is a fact that the code we write today is tomorrows legacy. Have you been working with legacy code? I guess all of us have already refactored, rewritten or translated legacy code in their professional career. It can be painful. It might also open up a new view on programming topics (like when I learned about COBOL for one of the projects I was involved in).

But since our own code, written today, will soon be legacy, what should we consider when we write that code?

For me, the documentation of the code is only a part. I’m a big fan of documenting the interface level contract of code. At the same time I’m all against documenting the body of functions (which imho is a violation of DRY). I mean, where is the sense of:

#Update each item <- stupid comment!!!
items.each { |item| item.update }

And that example brings me to this post’s title: writing less code will make life for those who have to deal with the legacy we are producing easier.

Less code can in my opinion be achieved by using the right programming language for the right job. The snippet in ruby above is self explanatory (even for someone who doesn’t know ruby well, all he/she has to learn here is the syntax for passing parameters into blocks). It can get more efficient with DSLs. Rails style of declaring associations is about as succinct as it can get.

For concurrent programs, using a language that supports concurrency on the language level like Erlang will make your code more terse.

I am not claiming that programs written in Ruby or Erlang or Scala or Haskell are easier to read than programs written in C# or Java. But I think that choosing the right language for the job can keep a lot of boilerplate out of your code. Some people claim that about 80% of the legacy code of any given system is boilerplate and infrastructure and only 20% are of business value (I would disagree in the case of COBOL though, my feeling is that it is more like 50/50 there). And exactly this is what makes working with legacy code annoying, tons of infrastructure to step through to find the few business parts your interested in.

Try to keep as much boilerplate and infrastructure out of your code, and the coders coming after you will thank you for this.

P.S.: Sure, you can write Java with that goal as well, keeping classes that contain business logic separated from classes that contain boilerplate, but most people don’t do it, because tha language doesn’t encourage it.

Who has done large scale JSF projects?

Whether successful or not, have you been involved in large scale JSF projects?

If yes, can you share some project statistics with the blogosphere and me in particular?

• The number of managed beans?
• The number of views?
• The number of custom components?
• The load on the server(s)? How many concurrent users?
• Which JSF implementation did you use?
• Did you use RAD tools?
• What where your pain points?
• What do you think is JSF’s sweetspot?
• Have you had concerns with bookmarkability?
• Would you write your next web-application using JSF and, if not, why not?
• Can you give a short description about the project?

I have been looking around for descriptions of real world JSF projects on the web but haven’t found many articles, so if you feel you can answer some of the questions above, please leave a comment or a trackback.

P. S.: If I have missed the definitive resource on projects done with JSF in my search, please tell me so.

My favorite eclipse classloading annoyance is fixed!

Yesterday evening I have spent about two hours helping an intern on an Eclipse problem.

Eclipse (3.0, actually IBM RSM 6) reported a NoClassDefFoundError for a class from one of the plug-ins.

I know that Error, I have had it before, and I dread it. Because this NoClassDefFoundError is a hoax! I got this error when the start method of the Bundle Activator would throw a NullPointerException when it was called because a class of that plug-in was requested. And yesterday evening it turned out to be a ClassNotFoundException for a class which was reported as a NoClassDefFoundError for the same class. The reason the class was not found was that the jar file containing the class was referenced under the wrong name in the manifest. Such things can happen. But throwing a NoClassDefFoundError instead of a ClassNotFoundException doesn’t make it easier to find the cause for the exception.

Today I took a look at the code (org.eclipse.osgi.framework.internal.core.BundleLoader.java) and found that there have been recent changes to it. Before, the findLocalClass method would try to call findLocalClass on the ClassLoader and return the class. It would also catch an ClassNotFoundException and return null. It wouldn’t log the exception or anything, just return null as if nothing exceptional had happend.

Now, the classloading mechanisms in OSGi are complex and the ClassNotFoundException can actually happen without causing a lot of trouble, because other classloading mechanisms will be called after “findLocalClass”.

The version currently checked into eclipse’s cvs repository will not only catch the ClassNotFoundException, it will also rethrow it. But only if it is a special TerminatingClassNotFoundException, a subclass which is constructed when the plug-in could not be activated which contains the actual exception as cause. This is great, because will can now see if the there actually was a NoClassDefFoundError or if the plug-in startup failed due to some other exception.

Still, I would really love to have anther patch in that code:

All ClassNotFoundExceptions which are not TerminatingClassNotFoundException should at least be logged. That way you could easily check the debug output without resorting to finding a log message “BundleLoader[BUNDLENAME].findLocalClass(CLASSNAME)” not followed by a “BundleLoader[BUNDLENAME] found local class CLASSNAME” but rather just look for the message telling you that the bundle you expected to find the class did not find it. So every time you get a NoClassDefFoundError, you could just swtich on the DEBUG logs and grep for the culprit class.

OK, it’s not much of an improvement, now that we have TerminatingClassNotFoundException, before this new excpetion I would have given, hmm, some money (not too much, though) for having that log message in there!

I have filed an feature request with an attached patch at eclipse.org ( 176828 ).

Q: What is almost as bad as a Singleton?

A: A class that has only static methods but also has (static) state.

In Java you often see XyzUtil or XyzHelper classes which only provide static methods (like, e.g., StringUtil from jakarta commons lang). These classes provide helper methods which usually act on an object which is passed along as an argument to the methods.

(Excursion: Java needs these static utilities because we can neither add new methods to a class without subclassing it and often cannot subclass the class we want to extend, like String, which is final. Ruby [and other languages] do not have this problem, since they provide the possibility to open a class and modify it or to use modules to mix in more behavior)

I don’t want to go into the question why I deem Singletons to be evil (I’m not the only one, just google for “Singleton evil”).

Now, a class which only has static methods and has a state is (imho) as bad as a Singleton, because it actually only is a Hidden Singleton, a way to work around the fact that the coding guidelines for a project don’t allow Singletons.

In the case I just stumbled upon such a hidden Singleton was used to retrieve a configuration object and to lazily create it, if it was not created before. So the first call to getConfiguration() created and stored (on a static field) a Configuration instance, and each further call just returned that instance. Now, first up, a getter should be idempotent anyway, but lets leave that aside. The class worked well in production settings. The first time the configuration was requested, it was created (which takes some time), afterwards the cached instance was returned. But during testing everything goes wrong. Using such a Hidden Singleton allows for the testing of only one Configuration. I can’t say: run this testcase with that configuration and this other testcase with that other configuration. The configuration was already loaded and won’t be modified.

So I either need a way to null the cached configuration on the Hidden Singleton, or need to get rid of it and replace it with some other pattern. What you usually want in such a setting is IoC, someone should simply set the configuration on all instances which need it (and such making those objects conform to the law of demeter, because they don’t need to fetch the Configuration from some other class). If you don’t have an IoC container, you might use a factory pattern to alleviate the pain the Hidden Singleton is causing. Use a factory to create the objects which need the Configuration. The factory can set the configuration on the objects during creation, and the configuration can be passed to the factory method (and, if really necessary, cached inside the factory until a different configuration is passed along…)

Browsing through the local bookstores

I’ve been browsing through the local bookstores yesterday and have been looking through the programming and IT sections. The two big bookstores I’ve been in both still haven’t got a section for Ruby. There are sections for everything you might (or then, might not) be looking for, Perl, PHP, Python, Java, C#, Joomla, Mambo, ActionScript etc. At the first bookstore I found one book about Rails, the other had four or five. Both had them filed under general programming. Both did not have a single book about Ruby (“The Ruby Way”, the “Pickaxe”, nothing).

That makes me question:

• How big is the acceptance of Ruby in Germany? and
• How big is the acceptance of Rails in Germany?

I have seen a few articles about Rails in german language magazines, but I somehow have got the feeling, that Ruby and Rails haven’t yet arrived in Germany yet.

Am I right? Or do I just look in the wrong places? At least there are 139 people from Germany registered at workingwithrails (as of today).

Workingwithrails lists two other developers in Freiburg, Germany. Maybe three is enough to start a ruby brigade? We’ll see.

My thoughts about "JSF is way too complicated?"

Imho, JSF is not too complicated. JSF was conceived for specific goals, and I think that JSF matches these goals very well. When you want to develop a java web application and can follow the path that JSF has laid out for you, you are well served. Integration with IDEs is available, RAD support, drag and drop development, it’s all included in the package. So, yes, JSF is not too complicated, if you use it the way it should be used.

JSF, e. g. , abstracts away the low level request-response layer inherent in all applications delivered over HTTP. I agree with Tim Shadel that the abstraction is leaky, but maybe programmers new to web development have something to gain from this abstraction.

It is only when you leave the troten path, when you make design decisions that were not considered in JSF, that JSF gets complicated. And even then, it is not actually JSF that gets complicated, but the fact that you have to work around a framework which was supposed to help you. It gets complicated because you have to dig through the seven layer burrito down to the request and the response to do what you want to do. Managed beans in request scope and bookmarkable URLs are, in my experience, things that have either not been considered in JSF, have been omitted on purpose or were, to the JSF creators, on the fringe of things considered necessary for a web framework.

I have done web development in Java since about eight years, starting out with Servlets going over JSP to JSF. I have also done web development in Perl, PHP and Python. And I currently do all my off-work projects in rails. Having worked with different frameworks written in different languages, I feel like there is a sweetspot between abstraction and allowing easy access to low level HTTP. And that sweetspot surely isn’t universal. But it seems that I share the same sweetspot with a lot of programmers. For me it’s rails. BUT: that does not mean that I would say that JSF is bad! It is just not a the level of abstraction I would like to work at.