All I Want for Christmas: BUG, from Bug Labs

This is one of the more interesting products I’ve seen in a while, and although it doesn’t look
like it’s going to be shipping in 2007, this is high on my wish list for 2008.

Bug Labs has created open source hardware modules that can be snapped together like Legos to create a mobile device. You start out with the well-equipped BUGbase, with built-in Wifi, USB, and ethernet. BUGbase has four connectors used for snapping on the open source hardware modules. Each module or combination of modules you snap on enables additional device capabilities. Current and upcoming modules include:

• Camera / videocamera
• GPS
• touch screen
• motion sensor / accelerometer
• qwerty keyboard
• speaker and jacks

Then comes the software, also open source and community-developed with Bug’s own SDK. It looks like there are a handful of applications out there currently, with most being of the test variety, but it doesn’t take long for these kinds of plug-ins to gather momentum.

Sure, these things look like bricks, but you can’t beat the gadget appeal.

Check them out at http://www.buglabs.net/.

Apache and Tomcat via Cpanel - Servlet Display Problems

Problem

Apache Web Server was not passing servlet requests to Apache Tomcat. Instead it served 404 errors, even though the Apache Tomcat Connector (JK 1.2, mod_jk) was auto-configured by the WHM / Cpanel installation.

Other Possible Descriptions of the Problem

• Jsp’s work in Tomcat, but servlets do not
• Apache Http Server won’t pass servlet requests to Tomcat
• Tomcat problems using the Cpanel plugin
• Virtual host configuration problem with Cpanel Tomcat
• Apache not recognizing servlets
• Servlets can’t be accessed through Apache

In the latest Cpanel Release (11.15.0-RELEASE 17853), Tomcat support has been integrated. Prior to this (I’m not sure for how long), Tomcat was available via a beta plug-in. I experienced this problem with both the beta plug-in and the integrated support.

What’s Happening

Apache Http Server accepts all web requests and determines which are requests for static content, and which requests should be forwarded to Tomcat.

Apache correctly serves static content, and correctly passes all requests for .jsp pages to Tomcat. But when a servlet is requested, e.g. www.myserver.com/myapp/myservlet, Apache looks for the “/myapp/myservlet” directory, and finding none, spits out a 404 error.

How to Resolve the Problem

I tried several things that I thought should work but did not, though I don’t know if it was due to my specific configuration or because they were just the wrong things to do. What finally solved the problem was just adding an .htaccess file to the root of the web application with the following lines:

SetHandler jakarta-servlet
SetEnv JK_WORKER_NAME ajp13

This forces Apache to forward all requests to resources within this context to Tomcat for processing, specifically to worker ajp13. Ajp13 is one of the default workers set up, and is defined (on my system) in /usr/local/jakarta/tomcat/conf/workers.properties.

Other things that I thought should work but didn’t (your mileage may vary):

1) In /etc/httpd/conf/jk.conf (if your httpd.conf file includes jk.conf),
add/edit the switch “+ForwardDirectories.” Normally, if Apache runs
across a directory it doesn’t recognize, it will spit out a 404. This
switch says to forward those requests to Tomcat, and let Tomcat spit
out a 404 if it can’t fulfill the request.

2) In /etc/httpd/conf/jk.conf (if your httpd.conf file includes jk.conf), specifically mount each context, and unmount static content. Mounting tells Apache to pass requests to Tomcat, and unmounting tells Apache to serve the content itself. Newer versions of Tomcat are faster than Apache at serving static content, but apparently, using Apache to serve static content is safer from a security perspective.

JkMount /mywebapp/* ajp13
JkUnMount /*.gif ajp13
JkUnMount /*.jpg ajp13

A separate issue that is outside the scope of this post is whether you should use Apache Web Server to front Tomcat requests, or whether you should just have Tomcat accept requests over port 80. If you’re using a recent Tomcat version (5.5+), Tomcat can serve both static and dynamic content faster than Apache.

Use Tomcat if: 1) you’re only dealing with a single server; 2) and you’re not using any other software that requires Apache (e.g. forums or wikis written in PHP).

Use Apache to front Tomcat requests if: 1) you want to load balance across multiple servers; 2) or you want different web applications or virtual hosts to be served by different processes.

Disclaimer

I know embarrassingly little about hardware, networking, or server setup. This solution might be a hack or it might be obvious to some more familiar with the components mentioned, but it couldn’t be resolved through a dedicated server help desk or through the Cpanel help desk, so I assume there are others out there that this could help. Everything in this post is based on my limited experience with the aforementioned software and my own research. If you know of a better, cleaner way to do this, or if you know how better to describe this problem or solution, please forward to me and I’ll amend this post.

Rationale Behind this Post

I recently (as in yesterday) resolved a difficult to diagnose problem involving Cpanel, Apache Web Server, Apache Tomcat, and the Apache Tomcat Connector (JK 1.2, mod_jk2). My googling skills tend to be above average, but I could find no reference to this specific problem anywhere, and the sole purpose of this post is to hopefully save someone else the aggravation. So please disregard the keyword-heavy text — it’s altruistic in nature, I assure you.

15,000 Downloads for Amazon-OnTheGo

We’re just wrapping up device support and SEO on our new mobile / web application (if all goes well, we’ll deploy in a week or two). Great stuff: mobile messaging, a maps mashup, location-based alerts, friend finder, and a place finder all wrapped up in one package called Swirl Connect.

In working on the SEO, I looked at Amazon-OnTheGo’s traffic stats, because it’s received a fair amount of traffic with very little effort on my part. It was always supposed to be a quick and dirty little project, but it’s attracted just over 15,000 downloads to date, and has received some good feedback along the way. Feedback I’m sorry to say I’m just getting around to seeing. Here are a few mentions:

• SarahInTampa.com: Amazon To Go Good luck with your move to WordPress!
• Amazon-OnTheGo on java.com
• 10 of 10 rating on GetJar
• Short mentions in SearchEngineWatch, Wendong’s Smart Phone Blog, ResourceShelf, and The Cell Freak.

Thanks for the feedback!

J2ME Polish 2.0 Beta 3: ScreenInfo Revisited

I thought I’d revisit Polish’s handy ScreenInfo class, as it is working as intended out-of-the-box in the beta 3 release (earlier post here).

In my current application, I’m using it a bit differently than I did before, combining it with a Timer to remove the ScreenInfo element after a specified amount of time.

As before, add the corresponding variable declaration to your build.xml file:

<variable name=”polish.ScreenInfo.enable” value=”true” />

You can also style this element in polish.css by using the “screeninfo” predefined style.

In the code sample below, I’m using images and determining margins at runtime, so I’m not utilizing this element, but it’s a quick way to add default styling and positioning.

screeninfo {
margin-top: 10
margin-left: 10;
}

A sample class file is below. In my implementation, I query for the canvas height and width during start-up (and I’d recommend you do something similar), but below is a quick and dirty way to accomplish roughly the same thing. This example could also be improved by accounting for multiple elements and related details.

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.util.Timer;
import java.util.TimerTask;
import de.enough.polish.ui.ScreenInfo;

public class MyMidlet extends MIDlet {
public Display display;
private List mainMenu;
private Timer timer;

public MyMidlet() {
//your constructor code here
}

public void startApp() { }
public void pauseApp() { }
public void destroyApp(boolean unconditional) { }
public static void quitApp() { }

public void showScreenInfo(int icon, long timeout) {
String imagePath = null;
switch(icon) {
case 1:
imagePath = “/si_mail.png”;
break;
case 2:
imagePath = “/si_sync.png”;
break;
default:
//
}

ScreenInfo.setImage(loadImage(imagePath));

//#ifdef polish.FullCanvasSize:defined
//#= int width = ${polish.FullCanvasWidth};
//#else
int width = 176;
//#endif

ScreenInfo.setPosition(width-32, 1);
ScreenInfo.setVisible(true);

timer = new Timer();
timer.schedule(new InfoTimer(), timeout);
}

public void removeScreenInfo() {
ScreenInfo.setVisible(false);
}

class InfoTimer extends TimerTask {
public void run(){
removeScreenInfo();
}
}
}

For more information, you can check out the Polish documentation related to ScreenInfo: Overview | JavaDoc

Job Scheduling with Quartz

I’ve recently become enamored with the Quartz job scheduling framework from OpenSymphony. While Quartz can be used in many types of applications, I ran across it looking for a solution to fire scheduled events in web applications. I wanted a Cron replacement that allowed me to instantiate and run any Java class in my application.

Before Quartz, I relied primarily on Caucho Resin’s runat tag to fire events. By adding a runat tag to the application’s web.xml file, you can call a servlet extending GenericServlet. Using Timers or application server-specific solutions is another option, but for the current project, I really wanted to start out with Tomcat, and I wanted the option to easily migrate to an application server if the need arose.

Quartz just works, and integrating it with an existing project was a snap. I approach most new tools and frameworks cautiously. The feature rich, easy to configure, and mature trifecta doesn’t come along as often as one would like, and I’ve been continually impressed with how carefully executed Quartz is.

There are three pieces that make a Quartz application: jobs, triggers, and the scheduler.

• Jobs: contain the logic or processing that you want to perform.
• Triggers: determine when jobs are run.
• Scheduler: the conductor that coordinates jobs and triggers.

Since I’ve started using Quartz, I’ve offloaded much of the on-demand processing into jobs of all sorts. Some jobs are used to perform routine maintenance, in a Ronco set it and forget it fashion, e.g. backups. Some jobs are used to generate pseudo-dynamic content, by running frequently in the background and generating static pages. This takes load off of the server, and conveniently aids in search engine spidering. Some jobs are traditional batch processing. For example, in the current project, a lot of geocoding is performed. Batching these requests, and running them every hour is much more efficient than firing them off on demand.

Adding to the flexibility of Quartz is the ability to schedule jobs both programmatically and declaratively, the ability to use listeners, the ability to persist jobs in a JobStore, and very versatile triggers.

Quartz is most definitely worth a look-see. The latest stable release is 1.5.2, and 1.6.0 alpha was recently released. Both can be download via OpenSymphony.

Amazon-OnTheGo: Screengrabs & Introduction

Amazon-OnTheGo is the result of a vanity project I undertook to port a Bluepulse widget to a full-blown Java ME application. With it, you can experience all of the best things about Amazon.com, on your phone:

• Search for products by keyword, ISBN number, or UPC code
• Access product details, used and new prices, images, user ratings, editorial reviews
• Maintain a shopping cart, and submit it to Amazon for purchase
• Find and review friends’ wishlists
• Get suggestions on similar items to view

Say you’re at the video store trying to determine what to rent. Fire up OTG, type in the UPC code, and check out the online editorial review. Maybe you’re at the local book store, and you can’t decide between two books. Type in their ISBN numbers to view ratings and comments. While you’re at, find out what the cheapest used price is.

Learn more about it and check out a video walk-through at the OnTheGo web site: www.mywebonthego.com (yes, most on-the-go and similar domains were snapped up long ago!). Go to the “Download” section to get it on your phone in any of three ways, or open http://m.mywebonthego.com with your phone’s WAP browser to download it directly.

More screenshots:

• otg-find-21.gif
• otg-details-31.gif
• otg-ratings-41.gif
• otg-releases-51.gif
• otg-similar-61.gif

Similar products: Scanbuy Shopper, featured on Lifehacker (coincidentally, right at the time OTG was released), except that it offers more search options

MIDP Project: Amazon-OnTheGo

Where has this post been lurking? It is incredibly past due, but better late than never.

By way of background, in May, I began a short project to convert a Bluepulse widget into a full-blown MIDP application. Read the project details here. The goals were to exercise the J2ME Polish 1.3 beta, get an application through the Verified process, and port Amazon-OnTheGo.

The project was mostly successful:

• I learned a lot about the 1.3 beta release of Polish, and posted a few experiences I had with some of the new features. Splash Screen | Screen Info | Framed Form
• I ported the Bluepulse widget to Java ME, and built out support for a reasonable number of devices.
• I signed the application for a good number of models, and wrote about application signing and Java Verified signing. Java Verified | MIDP Signing 2
• I built a web site and simple provisioning system around the application.

But I’m still in the midst of the Java Verified process, which takes longer than I anticipated. I’ll continue to post updates if I run across any discoveries during the remainder of this process.

And during this project, J2ME Polish went and released a new beta preview: J2ME Polish 2.0! Polish 2.0 adds Java 5.0 support, floating point support for CLDC 1.0 devices, and better IDE integration. It also adds some utility classes to assist with object serialization and RMS use. Considering some of the unresolved bugs from the 1.3 beta release, I have some doubts about the robustness of 2.0, but I’ll be testing it out in the coming weeks.

Within the next day, I’ll post a description of the Amazon-OnTheGo MIDP application, and instructions on how you can get it on your phone.

J2ME Polish, Just the Facts

I’m taking on a quick side project, which will begin in the next day or so, and I’ve decided to document a few pieces of that project. I’ll write more on that project later, but because most of those posts will make mention and use of J2ME Polish, I thought I’d introduce it today for those who aren’t familiar with it.

What is J2ME Polish?

J2ME Polish is a collection of open source tools used for creating wireless Java applications. Much of J2ME Polish is focused on MIDP applications, but recent releases also address Palm and RIM devices. The primary facets of J2ME Polish (from my perspective) are:

1) Build framework

J2ME Polish enables you to create builds targeted to certain devices or groups of devices. Using the device database and preprocessing, you can query for device capabilities and limitations, and fork your code at build time. Resource assembling enables you to conditionally include things like images or sound files targeted to certain devices.

Building for a device with a full color resolution of 240 x 320? Include large, full color icons. Building for a Motorola? Conditionally include an RMS size attribute in the JAD, and include 15 x 15 list icons. Want to display a fullscreen canvas? Query for fullscreen mode or Nokia UI support.

J2ME Polish also packages an extendable logging framework, giving you access to errors via emulators or the actual device; a localization framework; and takes care of the details of compiling, preverifying, obfuscating, and packaging your application.

2) GUI framework

J2ME Polish interlaces its UI classes with MIDP UI classes, enabling you to use traditional CSS techniques to style the interface of an MIDP application. This is a huge productivity booster. If your application must support MIDP1 devices, J2ME Polish transparently adjusts the MIDP2 to provide that support.

Some new custom items available include a SpiteItem, used to make animated menus, similar to web mouseover effects; a tabbed form; and a framed form, where a screen can be split into scrolling and non-scrolling frames.

J2ME Polish also packages a game engine, enabling you to quickly port MIDP2 games to MIDP1 phones.

3) Tools & Utilities

J2ME Polish brings ArrayLists to MIDP applications, and its TextUtil class offers functionality similar to that found in JavaScript array functions and Java’s StringTokenizer. The BitMapFont class and standalone editor enable you to create image-based fonts to use in your applications. Forget about Motorola’s 20 pixel system font!

J2ME Polish is available under both GPL and commercial licenses, depending on your project. Read more about J2ME Polish here.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development

Call for Entries: JBoss Innovation Award

‘Tis the season, I suppose.

“We want to hear how developers have used JEMS products to improve existing processes, overcome technology challenges, and enhance their company’s bottom line. Winning projects across several categories will be promoted and recognized at the largest worldwide JBoss community event, JBoss World in Las Vegas, June 12-15, 2006.”

Major award categories are Partner Innovation Awards, Best Practices Innovation Award, and Technology Innovation Award. Entries judged on creativity, impact, and presentation.

Tons of publicity and a free pass to JBoss World. Let’s face it, we all need a little Vegas now and again (and again).

Award Details | JBoss World Vegas 2006