Raible Designs

Apache 2 on OS X: Configuring mod_proxy and SSL

I recently had to setup Apache as a front-end web server for multiple backend servlet containers. The backend containers serve up different web applications, and the Apache front-end unites them from a hostname and port standpoint. The following instructions describe how to configure Apache 2 on Mac OS X to proxy requests to Tomcat or Jetty running on localhost:8080. It also shows how to enable SSL on Apache and force it for certain URLs in your Java web application.

Apache comes pre-installed on OS X, so you should be able to start it by enabling "Web Sharing" in System Preferences > Sharing.

$APACHE_HOME on Leopard is /etc/apache2. On Tiger, it's /etc/httpd. If you've upgraded Tiger to Leopard, it's likely you'll have both directories so make sure you're modifying the right one. I lost a few hours figuring this out, so hopefully this knowledge will appease some googler in the future.

Configuring mod_proxy

1. Open $APACHE_HOME/httpd.conf and add the following on line 480 - at the very bottom, just before "Include /private/etc/apache2/other/*.conf".

   #
   # Proxy Server directives. 
   #
   <IfModule mod_proxy.c>
       ProxyRequests On
       ProxyPreserveHost On
   
       ProxyStatus On
       <Location /status>
           SetHandler server-status
   
           Order Deny,Allow
           Deny from all
           Allow from 127.0.0.1
       </Location>
   
       ProxyPass    /myapp    http://localhost:8080/myapp
   </IfModule>

   ProxyPreserveHost allows request.getServerName() and request.getServerPort() to work as if there is no proxy server in place. In other words, even though Tomcat is running on 8080, request.getServerPort() will return 80.

2. The most important line is the last one as this is the dictates the location of your applications. Add more lines as you need to add more applications.
3. If everything is configured correctly, you should be able to run sudo apachectl restart and navigate to http://localhost/status. If you receive a "forbidden" error, make sure your /etc/hosts has an entry mapping 127.0.0.1 to localhost (as one of the last entries), or change "Allow from 127.0.0.1" to "Allow from localhost". If you get a "Server not found" error, you can tail the error log at "/var/log/apache2/error_log".

One issue I've seen with mod_proxy is when a request comes in and the backend server is down. When this happens, Apache returns a 503 Service Temporarily Unavailable and it doesn't seem to go away after the backend server is restarted. It does resume proxying after a while, but I haven't determined what causes the proxy to come back to life. If you know a setting that forces mod_proxy to check for the backend server on every request, please let me know.

Configuring SSL

1. Open $APACHE_HOME/httpd.conf and uncomment the following on line 470:

   Include /private/etc/apache2/extra/httpd-ssl.conf

2. Open $APACHE_HOME/extra/httpd-ssl.conf and change line 78 to:

   ServerName localhost:443

3. In httpd-ssl.conf, change line 99 to:

   SSLCertificateFile "/private/etc/apache2/ssl.key/server.crt"

4. In httpd-ssl.conf, change line 107 to:

   SSLCertificateKeyFile "/private/etc/apache2/ssl.key/server.key"

5. In httpd-ssl.conf, add the following after SSLEngine on to allow proxying via HTTPS:

   SSLProxyEngine on

6. Follow the Using mod_ssl on Mac OS X tutorial. For "Common Name/Server Name", use "localhost". You can download the source for mod_ssl (which you need at one point during the tutorial) at http://www.modssl.org/source/.
7. Run sudo apachectl restart and go to https://localhost. If you get a "Server not found" error, run sudo apachectl -t to verify the syntax of your config files or tail -f /var/log/apache2/error_log to verify there are no errors in the log files.

Forcing HTTPS for certain URLs
If you proxy requests from /myapp -> http://localhost:8080/myapp, request.isSecure() will return false. If you change it to /myapp -> https://localhost:8443/myapp, request.isSecure() will return true. I needed to figure out a way to have http://localhost/myapp go to http://localhost:8080/myapp and https://localhost/myapp to go http://localhost:8443/myapp. Even better, I wanted to configure things in a way so request.isSecure() returned the value based on the originally requested URL, not on the proxied URL. Configuration like the following would be ideal:

ProxyPass    http://*/myapp    http://*:8080/myapp
ProxyPass    https://*/myapp   https://*:8443/myapp

The solution I came up with is to standardize on secure URLs in my application. That is, use /secure/* as a prefix for all URLs that should be accessed via SSL. To follow this convention and force it, I added the following in my application's web.xml file:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>Secure Area</web-resource-name>
    <url-pattern>/secure/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

Once this is in place, accessing http://localhost/myapp/secure/index.html will result in an error. Accessing it using https will succeed. Following this, you can change your ProxyPass rules to the following and all requests to /secure/* will be https; other requests will be sent to http. The order of the rules below is important.

ProxyPass    /myapp/secure   https://localhost:8443/myapp/secure
ProxyPass    /myapp          http://localhost:8080/myapp

If this isn't a good strategy for you, Tomcat has the ability to use a redirectPort (in server.xml) that auto-redirects from http to https when CONFIDENTIAL is used in web.xml. I'm not sure if this redirect will carry through values from a form post.

Upgrading to Spring Security 2.0

This evening I spent a few hours and upgraded AppFuse to use Acegi Spring Security 2.0. The upgrade was fairly straightforward:

• %s/org.acegisecurity/org.springframework.security/g
• Upgraded dependencies (exclusions are necessary if you're using Spring 2.5.x and don't want 2.0.x dependencies pulled in):

  <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-core-tiger</artifactId>
      <version>${spring.security.version}</version>
      <exclusions>
          <exclusion>
              <groupId>org.springframework</groupId>
              <artifactId>spring-core</artifactId>
          </exclusion>
          <exclusion>
              <groupId>org.springframework</groupId>
              <artifactId>spring-support</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  ...
  <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-taglibs</artifactId>
      <version>${spring.security.version}</version>
      <exclusions>
          <exclusion>
              <groupId>org.springframework</groupId>
              <artifactId>spring-web</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  

• Changed taglib prefix from "authz" to "security" and change the associated taglib declaration to:

  <%@ taglib uri="http://www.springframework.org/security/tags" 
      prefix="security" %>
  

• In web.xml, I changed <filter-class> to org.springframework.web.filter.DelegatingFilterProxy. Since I didn't name my filter springSecurityFilterChain, I also had to add the following <init-param>:

      <init-param>
          <param-name>targetBeanName</param-name>
          <param-value>springSecurityFilterChain</param-value>
      </init-param>
  

• Lastly, I modified security.xml to use the new syntax. AppFuse's security.xml went from 175 lines to 33 with the new security namespace configuration!

It's hard to believe I first looked at Acegi almost 4 years ago. At that time, I said it contained too much XML for my needs. Ben's reaction:

Seriously, the "whole lotta XML" gives you exponentially more power and flexibility than a method such as this could ever hope to provide you.

It's nice to see that Spring Security 2.0 gives you exponentially more power and flexibility without all the XML. Thanks guys!

P.S. You can also view the full changelog for this upgrade.

Update: If you're using <authz:authentication property="fullName"/> in your JSPs, you'll need to change it to <security:authentication property="principal.fullName"/>.

History Meme

From my 17" MacBook Pro that sits at home and I don't use much on a day-to-day basis:

powers:~ mraible$ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
148 mvn
71 cd
46 sudo
40 ls
27 java
23 ll
17 svn
16 echo
13 vi
10 mate

From my 15" MacBook Pro that I use on a daily basis:

mraible-mn:~ mraible$ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
83 cd
81 ls
79 sudo
65 mvn
39 mate
28 svn
19 vi
15 rm
12 open
7 tail

Nothing too exciting.

TSSJS Vegas Begins

This morning, I woke up early and headed down to the opening ceremonies for TheServerSide Java Symposium in Vegas. Joseph Ottinger and Eugene Ciurana kicked off the show and welcomed the seemingly large audience of Java Developers. After the introduction, Neal Ford delivered a keynote titled Language-Oriented Programming: Shifting Paradigms. You can download Neal's presentation from the TSSJS Wiki (requires creating an account).

I started live-blogging Neal's keynote, but quickly gave up when I realized it was going to be a very good talk and I'd miss the essence of it if I tried to write it down. So I closed my laptop, sat back and enjoyed. Neal is an excellent speaker and did a great job of telling a story of the next evolution in Java Development. First off, he talked about artwork, the Renaissance and the Age of Enlightenment.

The plethora of Frameworks today is similar to the Renaissance (where everyone painted Madonna and Child) in that they're all very similar, and most of them are configured with XML. XML is the external DSL that configures the framework and its needed to allow late-binding and flexibility. The reason folks use XML is because of Java's limitations as a language. There are better mechanisms (languages) to construct this DSL. He gave examples using Ruby and Groovy. Furthering the notion of DSLs are Language Workbenches that allow programmers to write DSLs that are IDE-aware, so tools like IntelliJ IDE can offer code completion and such. If DSLs are the next evolution of programming, then tools like IntelliJ's MPS (to be open sourced before year end) are going to become very important.

I think one of the most important things I took away was that the building blocks for the next generation of development is already there. Neal referenced Ola Bini and his idea of the Polygot Language Platform. He showed the following image of what the Polygot Platform might look like, where the Stable Layer is written in Java, it has a low-ceremony/dynamic language on top of it, and then a DSL that pertains to the particular application. If we start developing using this type of platform, we'll quickly move into our own Age of Enlightenment - where we're still using all the frameworks, we're just putting a prettier face (DSL) on them.

This was a very good talk that I enjoyed immensely. I'm glad I sat back and listened instead of typing like mad.

After Neal's Keynote, I went to Brian Goetz's talk on Java Performance Myths. In this session, Brian talked about how object allocation is no longer slow, benchmark frameworks are often flawed, (uncontended) synchronization is not slow and a couple other things. The room was packed and 10-20 people ended up standing up in the back. I didn't learn anything revolutionary as this talk seemed to be written a couple of years ago.

Following Java Performance Myths, I headed to my room to get some work done. On the way, I discovered the "gas is out" at the Venetian and it's recommended folks go across the street to eat lunch and such. I'm about to head back to the conference to grab some grub - it'll be interesting to see if this situation has caused any lunch chaos.

An Irish Pub moves into the Neighborhood

In August 2006, I described how happy I was to be living in the DU Neighborhood and how we had so many good restaurants around. Today, I discovered there's a new Irish Pub that opened this week. While I don't live in the same house that I did in August 2006, I still live close by, a mere 5 blocks from Julie's house. While the old location was excellent, with Sushi, Indian and Liquor on the same block - my new location is 6 blocks from the Light Rail and a 1/2 block from the Elementary School Abbie and Jack will attend next year. DU is 5 blocks away - which is great for hockey games and gym memberships.

Why am I rambling on like this? I don't know, I just wanted to write down how much I like this neighborhood. With Spring starting yesterday, a beautiful day today and DU beating North Dakota last night - life is very good.

Today's agenda: skiing with the kids at Copper. WCHA Championship tonight.

The Thin Server Architecture Working Group

From The Wisdom of Ganesh:

Peter Svensson has set up a website where like-minded people can discuss the brave new world of applications whose common characteristic is that no aspect of presentation logic resides on the server side. I admit that's an overly broad-brush generalisation, and it will be necessary to read what the various authors of this camp have to say.

I thought about doing something similar when I first read about SOFEA. I'm glad to see that someone has taken on this challenge. However, doesn't it seem ironic that this site doesn't use SOFEA/SOUI for its own architecture?

IMO, if this site isn't written with some sort of SOFEA-based framework like it advocates, it's pretty much worthless.

The AppFuse Primer is now available!

From David Whitehurst's blog:

The AppFuse Primer is published! And, you can order your copy today. It's been a long road getting this done, but I'm excited about it and I hope you will be too. Please visit the site and consider the purchase of a copy today at http://www.sourcebeat.com/books/appfuse.html.

For more information, see SourceBeat's Press Release.

This book is as up-to-date as you can get. While I hope to do another AppFuse release in the coming months, this book should be up-to-date for quite some time.

Proposal accepted for OSCON 2008

From an e-mail I received earlier this afternoon:

We are pleased to accept the following proposal for OSCON 2008.

* Web Frameworks of the Future: Flex, GWT, Grails and Rails

It has been scheduled for 16:30 on 23 Jul 2008.

My Abstract:

What if the choices in web framework was reduced to 4? If RIA are the way of the future, it's possible that these 4 frameworks are the best choices for this development paradigm. This session will explore these frameworks, as well as entertain many other's opinions on the future of web development.

RESTful backends are easy to create with both Rails and Grails. Ajax frontends are simple to create and maintain with GWT. Flex gives you flash and a pretty UI. If you're an HTML developer, Rails allows you to quickly develop MVC applications. If you're a Java Developer, GWT + Grails might be a match made in heaven. This session is designed to help you learn more about each framework and decide which combination is best for your project.

I'm really looking forward to learning about GWT and Flex in the coming months. If you have any experience (or opinions) about the abstract above, I'd love to hear it. The louder the better.

For those who haven't been, OSCON is one of those truly special conferences. Possible reasons:

• It's only an hour from my parent's house
• It's a beautiful time of year in Portland
• It's always the same weekend as the Oregon Brewers Festival
• It's a kickass conference with the greatest diversity of Open Source Committers

I'm going for all 4 reasons and even made a reservation to stay at The Kennedy School. Should be a fun show.

My Entire Family is now on Macs

I bought my first Mac in January 2002. I had dreamed about a PowerBook for years before buying it and was very excited when it arrived. A couple days later, I discovered it was practically worthless because it was so slow for Java Development. I used it for pictures and music, but not much else. Through the years, I owned a couple more PowerBooks, but rarely found them fast enough to use on a day-to-day basis. I kept doing most of my development on Windows.

In January 2006, everything changed. I kept my Windows box around at home, but mostly because it was connected to my 23" monitor and I didn't feel like switching things out. When I moved last summer, I put my Windows box in a closet and bought a 30" monitor. I've hardly touched that Windows box since. Of course, it helps that I have Parallels installed on my Mac.

Now I have two MacBook Pros (a 17" I bought and a 15" that LinkedIn gave me). Last year I convinced my sister to buy a MacBook. Time I've had to spend in the last year helping her fix it: 0 minutes.

Yesterday, I took my Dad to his local Mac store and helped him buy a 24" iMac.

The Raible Family is now an all-Mac family and I work at an all-Mac company.

Life is good.

The LinkedIn Journey Continues

As you might know, I've spent the last several months working for one of the coolest clients ever: LinkedIn. They hired me back in July 2007 and I was impressed on day one. I was originally hired to help them evaluate open source Java web frameworks and try to determine if moving from their proprietary one to an open source one would help improve developer productivity.

After looking at all the options, I recommended we look at Struts 2 and Spring MVC - primarily because they seemed to be the best frameworks for a LinkedIn-type of application. Another Engineer and I prototyped with Struts 2 for about 6 weeks and came up with a prototype that worked quite well. While our mission was successful, we found a couple issues with Struts 2 and standard JSP that might actually hurt developer productivity more than it helped.

Following this project, I worked on the New Homepage Team, which is now visible to everyone that logs onto LinkedIn. My role was minimal, but it was still a very fun project to work on. You know those widgets in the right panel? I did the initial UI and backend integration for those. All the business logic, Ajax/JavaScript, CSS, and optimization was done by other folks on the team. Shortly after this project went live in November, I started prototyping again with Spring MVC + JSP.

The reason I was asked to prototype with Spring MVC was because they were using Spring on the backend, Spring MVC in a couple other projects, and a new project was being kicked off that used Grails. Rather than add another framework (Struts 2) to the mix, they wanted to see if they could suppress any further framework proliferation.

After a month of prototyping with Spring MVC + JSP, my results weren't as good as Struts 2. With Struts 2, I was able to use OGNL to do all the things their current JSP implementation allows them to do (call methods with arguments, use statics in EL, etc.). With standard JSP, a lot of this wasn't possible. If it was - it required writing lots of tag libraries and made it more cumbersome for developers to do certain things. At the end of that project, I determined that using FreeMarker might solve these problems. I also determined that neither Struts 2 nor Spring MVC would solve the ultimate problem of developer productivity. Neither framework would allow developers to go from make-a-change-and-deploy, wait-3-minutes-to-see-change-in-browser to make-a-change, save and wait-15-seconds-to-see-change-in-browser.

I recommended that this be the ultimate goal - to get rid of the deployment cycle and to allow minimal turnaround when deploying modified classes. After that problem was solved, it's true that moving to an open source web framework would likely provide an easier-to-remember API. However, the problem with moving to a new web framework would be that everything used to construct the existing site would suddenly become legacy code.

In the end, we concluded that the best solution might be to enhance the existing framework to be more like the available open source options. This would allow existing applications to keep using their code -- and if we enhance properly -- new applications can use a simpler, less verbose API and a templating framework that's easier to understand. We can make LinkedIn's version of JSP more like standard JSP while allowing its powerful EL to remain. We can add support for JSP Tag Libraries and Tag Files.

One of the benefits of moving to an open source web framework is there's a community, documentation and books that describe the best (or most common) ways to solve problems with the framework. LinkedIn has this, but it's all in code and no one seems to have a high-level of confidence that the way that they did it is the "best" way. Developers communicate well, but all the knowledge is stuck in their heads and inboxes - there's no way for new developers to search this knowledge and figure it out on their own without asking somebody.

By adopting an open source web framework, it's possible to solve part of this problem, but I think it's still going to exist - where a few engineers know how to use the framework really well (for the specific application) and the rest don't. We determined that regardless of open source vs. proprietary framework, what was needed was a set of developers that acted as authorities on how to develop web applications at LinkedIn. A UI Frameworks Team if you will. This would be their only job and they would never get pulled from this to work on projects or complete tasks related to LinkedIn's products. Some developers mentioned that they'd been asking for this for years, and some folks had even been hired for this. However, the formulation of this group has never happened and it's obvious (now more than ever) that it'd be awesome to have them.

The UI Frameworks Team
At the end of 6 months, it seemed my work was done at LinkedIn. I liked the idea of a UI Frameworks Team and recommended they start it with the authors of the existing web framework. They agreed this was a good idea. A few days later, I was pulled into the CTO's office and he offered me the job. He offered me the challenge of building this team and told me I could do it remotely (from Denver) and hire my own people to help me with it. I gulped as I realized I'd just been offered the opportunity of a lifetime. I knew that while this might not be the best option for LinkedIn, it certainly was an excellent opportunity for me. I said I'd think about it.

In the meantime, I was given a project which you might've read about. They asked me to migrate a Rails application to Grails and try to determine if they really needed both frameworks. I spent 2 weeks coming up to speed on both and flew to Mountain View to deliver my conclusion. Here's an excerpt from an internal blog post I wrote.

The application that I was asked to port from Rails to Grails? The one that was launched last week - LinkedIn Mobile.

After doing this research, I stepped up to the plate and accepted the offer to start a UI Frameworks Team and recruited some kick-ass Java Developers I know to be the founding members. Last week, I flew out to Mountain View to do some kickoff meetings and start getting the infrastructure in place so we can document, support and release code like a well-oiled open source project. There's nothing saying we won't use an open source web framework as the underlying engine, but I think this should be an excellent chance to see the power of open source governance and development style in a corporate environment.

Director of Engineering, Core Experience
I should mention one last thing. If you're an experienced Java Developer/Architect with a passion and deep knowledge of UI development (JavaScript, CSS, HTML), we've got a Director of Engineering, Core Experience position with your name on it. I might even get to interview you if you apply for this job. Furthermore, whoever gets hired will likely work very closely with my team. What's not to like about that!?