Workaround for mouse click problem in Ubuntu Karmic 9.10 Flash Player

After upgrading to Karmic I noticed that my HULU controls were unusable. After some experimenting I realized that the Flash Player was no longer recognizing my mouse clicks in Firefox. I came across a few solutions to the problem online but was suspicious about the reason. You can try these and they may work for you (careful with that shell script!), but I don’t like configuration changes that regress with each update I apply to my system.

If you want to just fix the Flash issue and get your HULU buttons back, try this: I am using Compiz as my window manager. If you are using Compiz and don’t have the Compiz Fusion Icon installed, install it with Synaptic and add it to your startup items. This will place a Compiz cube icon in your panel. Any time you experience the issue, just right-click the cube and choose “Reload Window Manager.” That will fix the issue, but not permanently. You will probably have to repeat this process in future sessions, but at least you can use Flash controls while you experiment with the longer term solutions listed above.

Hack Alert: Decorate 404 and other HTTP error pages with Sitemesh/Stripes

Dang. Second post and I’m already resorting to workarounds. This problem is particularly maddening, though, so any of you who have arrived at this page are probably at the point where you just want to make this work. Read on.

Lots of people have had problem getting Sitemesh to decorate error pages in their applications. You can create a custom error page and put content in it, but no matter what you do, you can’t get the boilerplate design decorations to render and you end up with a blank page with no head content and just the unstyled content you have put in the jsp.

I’ve seen people come across this error and it is not entirely clear who the culprit is in the stack. My config uses Stripes as the front controller, Sitemesh as the template/decoration engine, and everything is running on Jetty.

This is in the web.xml:

  1. <filter-mapping>
  2.     <filter-name>StripesFilter</filter-name>
  3.     <url-pattern>*.jsp</url-pattern>
  4.     <dispatcher>REQUEST</dispatcher>
  5.     <dispatcher>ERROR</dispatcher>
  6. </filter-mapping>
  7.  
  8. <filter-mapping>
  9.     <filter-name>sitemesh</filter-name>
  10.     <url-pattern>/*</url-pattern>
  11. </filter-mapping>
  12. <error-page>
  13.     <error-code>404</error-code>
  14.     <location>/not-found.jsp</location>
  15. </error-page>

…and the actual error page… (irrelevant layout markup removed)

  1. <%@include file="/WEB-INF/jsp/include/page_header.jspf" %>
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  5.     <title>Title Meh</title>
  6.     <link rel="stylesheet" href="/library/css/screen.css" type="text/css" media="screen, projection" />
  7. </head>
  8. <body>
  9.     <h1>Oops!</h1>
  10.     <p>The page you are looking for was not found.</p>
  11. </body>
  12. </html>

The problem seems to be that HTTP errors get routed around the decorator you have selected, even if you explicitly set a decorator for the page in decorators.xml. Instead, the unstyled error page is displayed raw. I’ve heard people say that the problem is a bug in Sitemesh and that it is fixed in newer versions, but even upgrading to 2.4.x does not solve the problem automatically. I’ve also heard people say that the problem is a Jetty bug, but I’m not sure about that because I’ve seen people complain of the same problem using Tomcat.

After a couple hours of wading through usergroups I have decided not to solve the problem but to bypass it in the name of getting something done for the day…

The (Temporary) Solution
This workaround is intended only as a stopgap only. It is not ultimately an acceptable solution as the stack should be handling this situation itself, but when the boss just wants to see rounded corners on the error page, here is what to do:

Add the following to the top of your not-found.jsp page above the Doctype declaration:

  1. <%
  2.     if (request.getParameter("show") == null) {
  3.         response.sendRedirect("not-found.jsp?show=true");
  4.         return;
  5.     }
  6. %>

When the page loads without the “show” parameter present, it will redirect back to itself. This has the effect of triggering a normal routing event that is then picked up by Sitemesh and decorated like all other normal requests. The page will reload and … win! Your page will be styled as expected and wrapped in whatever boilerplate code you have defined in the decorator.

The selection of “show” as the URL param to test for was arbitrary. You can use any parameter you want, as long as it isn’t a parameter used elsewhere in the application.

My hope is that somebody reading this will see what I’ve done wrong and correct me so that we can all benefit from the ultimate solution to the problem, but for those of you who are just desperate to see the expected behavior, this will hopefully make your day a little better!

Recursively delete Dreamweaver _notes directories in Subversion

Every once in a while I inherit a site that was built in Dreamweaver. I’m not anti-DW by any means. I think it has a great code view, and the Find/Replace function is epic for making mass updates to an existing site.

What I DON’T like is polluting my Subversion repository with old _notes folders generated by DW for template and file synchronization operations. It’s easy enough to delete all of the folders, but that will cause trouble for you when you try to commit and Subversion can’t figure out what happened to the files. Worse yet, an update before committing just plops those folders right back in place.

The solution is to use subversion’s delete function in combination with core shell tools to quickly remove all those files and keep Subversion informed of the changes.

Just cd to the top of your SVN working copy and do:

svn rmĀ  `find . -type d -name _notes` --force

The –force flag is not necessary unless you have accidentally opened your project in DW to do a quick S&R and find that a bunch of unversioned _notes folders have appeared. Using –force just makes sure that you get both versioned and unversioned instances without any warnings.