I wanted to trace exactly what happens when a JSF page uses a redirect. Here are my experiences with the HTTP and TCP/IP monitors in NetBeans and Eclipse, and why I ended up using Wireshark instead.
Consider the usual JSF flow. The client makes a GET request for the first page. That's a special case, but from then on everything follows a pattern. The server renders a page containing an HTML form that is to be posted back to the same URL. The client makes a POST, the server navigates to a new page and renders it. The problem is that the browser requested the new page with the old URL, and so the browser bar URL is always one step behind.
You can fix that with a redirect. If you use JSF 2.0 “EZ navigation”, you produce outcome strings like this.
if (...) return "success?faces-redirect=true" else return "failure?faces-redirect=true"
So, what exactly happens now? That's where HTTP monitoring comes in.
In Netbeans, you activate HTTP monitoring by checking “Enable HTTP monitor” in the GlassFish server properties.
You can then see the traffic in the HTTP Server Monitor tab. For example,
here you can see the initial GET, the POST to /faces/index.xhtml
,
and the GET to /success.xhtml
.
Unfortunately, NetBeans doesn't show you what the server returns to the client, so you don't see why that second GET request was made.
The Netbeans HTTP monitor modifies
the
domain1/config/default-web.xml
file, adding a filter to every
web application. That filter is left in place after Netbeans exits. If you run
the application from inside Eclipse, the filter will throw an exception. The
remedy is to turn monitoring off before exiting Netbeans.
Eclipse uses a different approach. It can monitor
arbitrary TCP/IP traffic. With Glassfish, right-click on the server in the
Servers tab and select Monitoring > Properties. Then click on Add and select
port 8080. Select Start to actually start monitoring. Then you need to point
your browser to localhost:8081/contextRoot/faces/index.xhtml
.
Eclipse routes the packets from port 8081 to port 8080, which gives it a chance
to monitor them.
As you can see here, Eclipse shows what the server sends back to the client.
Well, almost. What you don't see are the HTTP headers, so you don't see how the browser knows where to go. (The browser doesn't parse the HTML that you see in the screen capture—that's for people who turned off automatic redirect in their browser.)
To really see what is going on, I used Wireshark. It captures all TCP/IP traffic, doesn't install any filters in your app server, and doesn't make you change port numbers. It decodes HTTP, showing you the entire response:
As you can see, the server sets the Location
header to the
redirect location.
Executive summary: The HTTP and TCP/IP monitors that are built into the IDEs are useful for routine traffic monitoring, but for hardcore sniffing, Wireshark is hard to beat.