Matt RaibleMatt Raible is a writer with a passion for software. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "servlet". 226 entries found.

You can also try this same search on Google.

OSCON 2007: Comparing Java Web Frameworks

This afternoon I delivered my Comparing Java Web Frameworks talk at OSCON in Portland. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (5.1 MB)

For comments on this presentation from earlier this year, see related postings from ApacheCon EU and JA-SIG. This presentation is pretty much the same as the one from ApacheCon and JA-SIG, except it has a different theme and I chopped out the Sweetspots section (due to time constraints).

Portland is great this time of year, but unfortunately I won't be sticking around. I'm heading down to Salem to work remotely for a couple of days, returning for the Oregon Brewers Festival on Friday and heading back to Denver on Saturday. I'll be glad when July is over - I've traveled to a new state every week.

Posted in Java at Jul 25 2007, 04:50:55 PM MDT 9 Comments

Thoughts on MyFaces 1.2 vs. JSF RI

Yesterday, MyFaces 1.2 was released. I took the opportunity to upgrade AppFuse Light and found it surprisingly easy to do so. The only issue I ran into is my testing logic no longer works. I haven't had a chance to dive deeper into trying to fix the problem, but I did check the code in.

Since I'm using Facelets with MyFaces, I figured it should be possible to run my app on Tomcat 5.x. No dice. I tried replacing MyFaces with Sun's RI (version 1.2_04) and voila! - it works.

From what I learned yesterday, it appears that MyFaces 1.2 will only run on a container that supports JSP 2.1. Sun's RI, on the other hand, will run on a Servlet 2.4/JSP 2.0 container. I don't know if Sun's RI is doing things properly, but it doesn't seem like Servlet 2.5 is required (which is kinda nice IMO).

You might ask why I care about JSP 2.0 vs. JSP 2.1? In reality, I don't. However, if I were to mix and match Struts 2 and JSF in the same application (using the Struts 2 JSF Plugin), I'd like to do it on a JSP 2.0 container. Why? Because OGNL (the EL in Struts 2) uses the pound sign (#) for expressions and JSP 2.1 hijacked that. Until the Struts team fixes that, I'm stuck on JSP 2.0. The workaround (disabling EL for all JSPs) doesn't seem like a good option to me.

Posted in Java at Jul 19 2007, 11:32:18 AM MDT 7 Comments

Java Web Frameworks and XSS

In preparation for my talk at OSCON next week, I've been doing some research on cross-site scripting and how good Java web frameworks handle it. I'm disappointed to report that the handling of XSS in Java web frameworks is abysmal. First of all, the JSP EL doesn't bother to handle XSS:

With JSP 2.0 you can use the following to emit the description of a "todo" item:
${todo.description}
That's pretty nice. What happens when someone has entered a description like this?
<script type="text/javascript">alert('F#$@ you!');</script>
Well, it executes the JavaScript and pops up a nice little message to you.
...
My question is this: Why in the world did the expert group on the JSP 2.0 JSR decide to make not escaping XML content the default for EL expressions, when they made the opposite decision for c:out?

(Emphasis mine) If a company/developer wants to make sure their JSP-based code is not susceptible to XSS, they have two choices (as I see it):

  • Do lots of code review to make sure <c:out> is used instead of ${}.
  • Hack the jsp-compiler/el-engine to escape XML by default.

The good news is #2 doesn't seem to be that hard. I pulled down commons-el yesterday, added a hack to escape XML, re-jarred and put it in Tomcat 5.0.25's classpath. This actually worked and I was impressed it was so easy. However, when I looked at Tomcat 6, commons-el is no longer used and now there's a "jasper-el.jar" in the lib directory. I don't mind modifying another library, but what's the difference between jasper-el and commons-el?

Of course, the whole problem with JSP EL could be solved if Tomcat (and other containers) would allow a flag to turn on XML escaping by default. IMO, it's badly needed to make JSP-based webapps safe from XSS.

On a related note, there's a couple of web frameworks that I've found to be susceptible to XSS: namely Spring MVC and Struts 2. For Spring MVC, its <form:input> and <form:errors> tags are vulnerable. For Struts 2, OGNL expressions are evaluated, which is way worse than XSS and actually allows you to shutdown the JVM by putting %{@java.lang.System@exit(0)}" in a text field.

Even though it was surprising for me to see the issues with Struts 2 and Spring MVC, I'm somewhat glad they exist. If I hadn't discovered them, I might blissfully think that Java web frameworks aren't susceptible to XSS. However, it appears they're not only susceptible, but no one is really thinking about XSS when developing these framework. To further prove that theory, the Spring MVC and Struts 2 teams are aware of these issues, have been for quite some time - yet they've done nothing in the form of releasing upgrades or patches.

Seems kinda strange doesn't it?

Posted in Java at Jul 19 2007, 10:16:15 AM MDT 26 Comments

AppFuse 2.0 M5 Released - now with CRUD generation and XFire support

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M5! This release marks a milestone in the features of AppFuse 2.x. This release adds CRUD code generation, full source support (just like 1.x) and XFire integration. In addition, we've fixed all the issues related to switching persistence frameworks, and you should now be able to easily switch from using Hibernate to to iBATIS or JPA. The videos have been updated for M5. The Easy CRUD with Struts 2 video shows how code generation currently works.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide or the Hello World video.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ and join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

For more information, please see the 2.0 M5 Release Notes. If you'd like to use AppFuse offline (or download everything at once), you may want to grab the dependencies and extract them into your ~/.m2/repository directory.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

  • Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
  • Java 5 for Development (Java 1.4 for deployment using the Retrotranslator Plugin)

Comments and issues should be posted to the mailing list.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.

Update: The videos are much lower quality than the ones I originally recorded (13 MB vs. 70 MB). If you want to view the high quality videos (they're much clearer), you can download them from java.net. If someone has a better way to compress these (I just used QuickTime's Export feature), please let me know.

Also, this release contains the first release of the AppFuse Maven Plugin. This plugin is largely based on Hibernate Tools. We modified many of the FreeMarker templates from Hibernate Tools to default to certain annotations, as well as clean up the formatting. These templates are currently available in AppFuse's SVN. Hopefully making them available is enough to satisfy Hibernate's LGPL license.

Posted in Java at May 23 2007, 05:49:10 PM MDT 16 Comments

Configuring Tomcat for Production

From The Atlassian Developer Blog:

You appear to be running Tomcat in development mode. (http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html)

This means that source of every JSP is held in memory to provide detailed messages in the event of an error. If you have large JSPs this will hurt. It looks like this accounts for 50MB+

From Tomcat's Production Configuration documentation:

The main JSP optimization which can be done is precompilation of JSPs. However, this might not be possible (for example, when using the jsp-property-group feature) or practical, in which case the configuration of the Jasper servlet becomes critical.

When using Jasper 2 in a production Tomcat server you should consider making the following changes from the default configuration.

  • development - To disable on access checks for JSP pages compilation set this to false.
  • genStringAsCharArray - To generate slightly more efficient char arrays, set this to true.
  • modificationTestInterval - If development has to be set to true for any reason (such as dynamic generation of JSPs), setting this to a high value will improve performance a lot.
  • trimSpaces - To remove useless bytes from the response, set this to true.

Seems like good information to know.

Posted in Java at Apr 16 2007, 04:05:03 PM MDT 1 Comment

Mixing Apache HTTP Server, mod_rewrite and mod_jk

I'm trying to configure Apache and Tomcat to work with a desired architecture for doing A/B Testing on my current project. Our basic idea is that we'll deploy entirely new WAR files when we have a test, then use the magic of Apache's mod_rewrite, mod_jk and possible the UrlRewriteFilter to keep the URLs somewhat consistent between version A and version B. Here's some questions I have for those folks who might've done this before:

  1. Is it possible to use Apache's mod_rewrite to map http://www.domain.com/?v=1 to http://www.domain.com/1 (this allows us to have two different applications/wars served up to the same domain).
  2. If #1 is possible, what's the RewriteRule for allowing the parameter to be anywhere in the query string, but still allowing the target to use it as the context name?
  3. Is it possible to use something in the WAR (likely the UrlRewriteFilter) to produce HTML that has rewritten links (i.e. http://www.domain.com/?id=1 in the WAR whose context is 1)?

In other words, can Apache forward to the correct app going in, and can that app rewrite its URLs so those same URLs are used when going out?

I believe this is all possible. However, I am having difficulty getting mod_jk to allow mod_rewrite to be processed first. If I have the following in httpd.conf, it seems like htdocs/.htaccess gets bypassed.

JkMount /* loadbalancer

Is it possible to configure Apache/mod_jk so WARs can hang off the root, but still use mod_rewrite? If not, the only solution I can think of is to use UrlRewriteFilter in the WAR to forward to another context when a "v" parameter is in the URL. Currently, the UrlRewriteFilter doesn't allow forwarding to another context. The good news is the Servlet API allows it. I got it working in Tomcat (with crossContext enabled) and wrote a patch for the UrlRewriteFilter.

Anyone out there have experience doing A/B Testing in a Java webapp? If so, did you try to disguise the URLs for the different versions?

Update: I've got a bit of this working. The magic formula seems to be don't try to hang things off the root - use mod_rewrite to make things appear to hang off the root.

First of all, I posted a message similar to this post to the tomcat-user mailing list. Before I did so, I discovered mod_proxy_ajp, which happens to look like the successor to mod_jk. AFAICT, it doesn't allow fine-grained rules (i.e. only serve up *.jsp and *.do from Tomcat), so I'll stick with mod_jk for now.

Rather than proxying all root-level requests to Tomcat, I changed my JkMount to expect all Tomcat applications to have a common prefix. For example, "app".

JkMount /app* loadbalancer

This allows me to create RewriteRules in htdocs/.htaccess to detect the "v" parameter and forward to Tomcat.

RewriteEngine On

RewriteCond     %{QUERY_STRING}     ^v=(.*)$
RewriteRule     ^(.*)$              /app%1/ [L]

This isn't that robust as adding another parameter causes the forward to fail. However, it does successfully forward http://localhost/?v=1 to /app1 on Tomcat and http://localhost/?v=2 to /app2 on Tomcat.

What about when ?v=3 is passed in? There's no /app3 installed on Tomcat, so Tomcat's ROOT application will be hit. Using the UrlRewriteFilter, I installed a root application (which we'll likely need anyway) with the following rule:

    <rule>
        <from>^/app(.*)$</from>
        <to type="forward">/</to>
    </rule>

So I've solved problem #1: Using URL parameters to serve up different web applications. To solve the second issue (webapps should rewrite their URLs to delete their context path), I found two solutions:

  1. Use mod_proxy_html. Sounds reasonable, but requires the use of mod_proxy.
  2. Use the UrlRewriteFilter and outbound-rules.

Since I'm using mod_jk, #2 is the reasonable choice. I added the following link in my /app1/index.jsp:

<a href="<c:url value="/products.jsp"/>">link to products</a>

By default, this gets written out as http://localhost/app1/products.jsp. To change it to http://localhost/products.jsp?v=1, I added the following to urlrewrite.xml:

    <outbound-rule>
        <from>^/app1/(.*)$</from>
        <to>/$1?v=1</to>
    </outbound-rule>

This produces the desired effect, except that when I click on the link, a new session is created every time. AFAICT, I probably need to do something with cookies so the jsessionid cookie is set for the proper path.

Not bad for a day's work. Only 2 questions remain:

  1. What's a more robust RewriteRule that doesn't care about other parameters being passed in?
  2. What do I need to do so new sessions aren't created when using an outbound-rule?

It's entirely possible that mod_proxy_ajp with mod_rewrite_html is best tool for this. Can mod_proxy handle wildcards like JkMount can? I've heard it's faster than mod_jk, so it probably warrants further investigation.

Update 2: I achieved the desired result using mod_rewrite, mod_jk and the UrlRewriteFilter (for outgoing links). Here's what I put in htdocs/.htaccess (on Apache):

RewriteEngine On

# http://domain/?v=1 --> http://domain/app1/?v=1
RewriteCond     %{QUERY_STRING}     v=([^&]+)
RewriteRule     ^(.*)$              /app%1/$1 [L]

# http://domain --> http://domain/app (default ROOT in Tomcat)
RewriteRule     ^$                  /app/ [L]

And in the urlrewrite.xml of each webapp:

   <outbound-rule>
       <from>^/app([0-9])/([A-Za-z0-9]+)\.([A-Za-z0-9]+)$</from>
       <to>/$2.$3?v=$1</to>
   </outbound-rule>

   <outbound-rule>
       <from>^/app([0-9])/([A-Za-z0-9]+)\.([A-Za-z0-9]+)\?(.*)$</from>
       <to>/$2.$3?$4&amp;v=$1</to>
   </outbound-rule>

Next I'll try to see if I can get it all working with mod_proxy_ajp and mod_proxy_html. Anyone know the equivalent of "JkMount /app*" when using LocationMatch with mod_proxy?

Posted in Java at Apr 16 2007, 12:07:10 PM MDT 11 Comments

AppFuse 2.0 M4 Released

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M4! This release marks a milestone in the usability of AppFuse 2.x. A lot of folks (including myself) have been using AppFuse 2.0 on projects and have fixed quite a few issues. In addition to polishing the tutorials, we've fixed a fair amount of i18n bugs and packaging issues with modular archetypes.

We were hoping to get AMP's code generation and XFire integrated in M4, but were it's going to have to wait until M5.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ and join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

  • Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
  • Java 5 for Development (Java 1.4 for deployment using the Retrotranslator Plugin)

For more information, please see the 2.0 M4 Release Notes. To see how AppFuse 2.x works, please see the video demos.

Comments and issues should be sent to the mailing list.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.

Posted in Java at Mar 24 2007, 04:33:21 PM MDT 5 Comments

Message Driven POJOs by Mark Fisher

Last night, I attended the New England Java Users Group to see Mark Fisher talk about Message Driven POJOs. This was the first JUG I've been to (outside of Denver's) where I was an attendee instead of a speaker. It was interesting to see how they do things. They have one main speaker who speaks for two hours. After the first hour, they have a break, offer pizza and do a raffle. Then the speaker continues. They require you to "register" at least 48 hours before the meeting starts. This is because the meeting is held at Sun and they (apparently) need to do it for security purposes. They actually checked my ID and made sure I was registered at the door. After I passed their verification test, I received a name tag. While I like Denver's Basic Concepts followed by Main Speaker setup, I liked that this JUG meeting was over at 8:15. Below are my notes from the event.

Topics in this Session: Overview of JMS, Spring's JmsTemplate and implementing a Message Driven POJO.

Goals of JMS: provide a vendor-neutral abstraction for accessing Message Oriented Middleware from Java. It provides for enterprise messaging systems what JDBC provides for relational databases. See Wikipedia's definition of JMS for more information.

The API is what insulates your code from the JMS implementation you're using. The JMS implementation will use a message broker to communicate between servers. Tonight, Mark will be using ActiveMQ in his examples. He plans on doing most of his presentation in Eclipse because he's been spending 14 hours per day in PowerPoint revamping Interface21's training courses (I don't miss that at all).

The JMS Message is the central object to JMS. There's various types of messages, TextMessage, ObjectMessage (I missed the rest). Two types of JMS Destinations are available: Queues and Topics. A JMS Session is used to create messages as well as producers and consumers. Examples calls:

  • session.createTextMessage(String)
  • session.createConsumer(dest)
  • session.createProducter(dest)

A JMS Connection is obtained from a JMS ConnectionFactory. The ConnectionFactory is typically accessed by a JNDI Lookup.

JMS is most commonly used for internal application communications (not public facing).

Templates are common in the Spring Framework and are used to simply API usage. Their main goal is to reduce boilerplate code (resource management, try/catch, etc.). Examples include JdbcTemplate, JpaTemplate, JndiTemplate, TransactionTemplate and (you guessed it) JmsTemplate. Spring also translates exceptions to consistent runtime hierarchies. In addition to one-line methods, Spring's templates supply callbacks that alleviate try/catch blocks - but give you full power of the API.

JmsTemplate has a couple of capabilities: it handles acquisition and release of resources and translates checked JMS Exceptions to a parallel hierarchy of RuntimeExceptions. It's also capable of converting a payload to the corresponding JMS message type with a MessageConverter strategy. Lastly, it provides convenience methods to allow sending asynchronous messages.

Now Mark is showing us how you configure a ConnectionFactory, Queue and JmsTemplate in a Spring context file. The first couple of beans only take 3 lines of code to configure, the 3rd one takes 4 because it has a dependency on the first two. Pretty easy configuration if you ask me. After composing bean definitions, Mark created a JUnit test and called jmsTemplate.convertAndSend() to send a message in 2 lines of Java code.

To receive messages with JmsTemplate (pre Spring 2.0), you could use synchronous receive calls: receive(), receive(Destination) and receive(String). There are also receiveAndConvert() methods.

In Spring 2.0, they added the ability to do MessageListener containers to enable asynchronous reception in a non application server environment. Implementations include SimpleMessageListenerContainer, DefaultMessageListenerContainer and ServerSessionMessageListenerContainer. The DMLC adds transactional behavior, and the SSMLC hooks into the server's SPI. Spring's MessageListenerAdapter enables the delegation to a POJO for handling the payload.

For the next 1/2 hour or so, Mark wrote a bunch of Java and XML to create a simple Trader application. About the same time, I got managed to get an internet connection from somewhere and started browsing the net and answering e-mail. Every once in a while I looked up to see Mark's code - it all looks very simple and straight forward. In Spring 2.1, a <jms:*> namespace will be added to simplify the XML configuration.

For those of you out there using Spring's JMS support - are there any issues you've run into? Are you using it in production? It's always pimped as "awesome", so I'm looking for pain points that folks might encounter when using it.

Related: Spring's JMS Documentation and ActiveMQ's JmsTemplate Gotchas.

Posted in Java at Feb 23 2007, 11:25:59 AM MST 6 Comments

AppFuse 2.0 M3 Released

The AppFuse team is pleased to announce the release of AppFuse 2.0 M3! This release marks a milestone in our documentation efforts. We've completed all of the web framework tutorials and ensured that all the archetypes work properly. Turkish language support was added and native2ascii was integrated so all i18n bundles should work properly.

The major things missing from this release are code generation (AppGen) and web services (XFire) support. We hope to add both of these before the final release.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

  • Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
  • Java 2 Standard Platform Edition (J2SE) 5.0

For more information, please see the 2.0 M3 Release Notes.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun. ;-)

Posted in Java at Feb 06 2007, 02:16:45 PM MST 16 Comments

Maven 2 hates Commons Logging

It's true that most people hate commons-logging, but Maven 2 hates it even more. There are many open source projects that use this library, so you're likely to depend on it when you never intended to. Of course, this is Maven 2's transitive dependencies fault - but currently there's no option to turn transitivity off. I tried changing to SLF4J, but that causes some Maven plugins to fail.

Since the Maven team refuses to fix this (even though it's an *obvious* exception to their rule about not changing anything), I've fixed it myself. The AppFuse repo has a fixed version of commons-logging's pom.xml. To get the fixed version of commons-logging, delete it from your local repo, then add AppFuse's repository to your pom.xml:

    <repositories>
        <repository>
            <id>appfuse</id>
            <url>http://static.appfuse.org/repository</url>
        </repository>
    </repositories>

Since the burden of this issue clearly rests upon the shoulders of the commons-logging developers - can we please get a new release with a fixed pom? Pretty please?

Update: I tried to get slf4j to work again today. While I succeeded, I found a critical bug. The bug is that log messages don't print out the method name, just debug(), info() or whatever from your classes. It's possible to fix this by using slf4j instead of clogging. However, that won't help you get method names printed when cranking up the logging for 3rd party libraries like Spring and Hibernate. Since this won't be fixed, it seems better to stick with commons-logging. I doubt I'd have any luck getting all the libraries that AppFuse uses to move away from commons-logging.

Posted in Java at Feb 04 2007, 10:43:15 PM MST 11 Comments