I haven’t worked on my wife’s recipe site in ages. Originally written as an experiment with JSP and Java, I think my mom and Karen are the only people that use it (which is fine with me). In any case, I recently moved it to a new host and saw a weird issue pop up in catalina.out where any INSERT, UPDATE or DELETE statements were erroring out with the message:
java.sql.SQLException: Can not issue data manipulation statements with executeQuery()
Turns out that earlier versions of the MySQL JDBC driver allowed you to run INSERT / UPDATE / DELETE statements using the executeQuery() method of the PreparedStatement class, which violated the JDBC specification, but worked nonetheless. The newer versions are JDBC compliant and don’t allow that behavior, which causes the above mentioned SQL exception. More from the MySQL forums.
Category Archives: J2EE
Modifying Memory Allocation on Tomcat 5.x on Windows
A search for ‘tomcat 5 outofmemory windows‘ returns about 2000 hits, not one of them shows you how can increase the amount of memory allocated to Tomcat via the Apache Tomcat Properties applet when running on Windows (some point to this Tomcat configuration document which seems to be a bit out of date). Start –> Programs –> Apache Tomcat 5.0 –> Configure Tomcat –> Java. The “Initial memory pool” corresponds to the JVM -Xms option (~ initial Java heap size), the “Maximum memory pool” corresponds to the JVM -Xmx option (~ maximum Java heap size) and the “Thread stack size” corresponds to the JVM -Xss option. The picture book follows:
You can read more about the non-standard options on java.sun.com.
Configuring Apache James to send email via a smart host
Unfortunately we’re still using Windows on our servers at work, the last application I deployed didn’t have IIS installed on it (yay!), which means no local SMTP service. I needed a local SMTP server so I installed Apache James (I know, it’s probably overkill, but we might use some of it’s other features later). Anyway, buried deep in the SMTP Virtual Server properties applet in IIS is the ability to configure the server to send all email through another server; in IIS parlance this is called a ‘smart host‘. James (love the name btw) doesn’t have a ‘smart host’ option property sheet, but you can get the same functionality by using the <gateway> and <gatewayPort> elements of config.xml (buried in $james_install/apps/james/SAR-INF/config.xml). Read up on the options under RemoteDelivery.
Doug Cutting interview on TSS
The guys at TSS did a pretty indepth interview with Doug Cutting (who wrote Lucene and is now involved in the Nutch project). You can read the transcript here; there’s video there somewhere, I just couldn’t find it.
Using Betwixt, Struts and REST
My latest project at work launched a couple weeks ago, unfortunately there isn’t much to look at, but it’s not like I’m a Flash developer, so unless I start writing Windows apps, no one will ever be able to see my work anyway. Alas, a major portion of the project involved consolidating some business logic behind a SOAP API (I’ll go into that some other time). We were supposed to be moving our front end to ASP.NET but at the last minute, the ASP.NET migration didn’t happen so we ended up needing something that ASP could use as well, which meant REST. With the business logic wrapped up behind business delegates, all that was needed as a Servlet Filter to map requests for /myapp/xml to a Struts Action class, which invoked the business delegates and then returned XML to the client. Now on the SOAP end of things (Axis embedded in Tomcat), I didn’t have to deal with XML (Axis handles all the XML serialization and deserialization). But with REST you’re in conundrum: do you create toXML() methods on all of your JavaBeans? do you put the JavaBean or collection of beans in the Request scope and then generate the XML using JSP? Those options all seemed error prone and harder to test. I looked at JAXB (makes more sense when you have XML that you want to turn into a JavaBean) and Castor (same thing) but finally decided on using Betwixt, a Jakarta Commons library that provide a simple way of turning a JavaBean into XML. The end result looked something like this:
public class RESTAction extends DispatchAction {
public ActionForward doSomething(...) {
MyBean bean = BusinessLogic.getBean();
response.setContentType("text/xml");
OutputStream sos = response.getOutputStream();
BeanWriter beanWriter = new BeanWriter(sos);
BindingConfiguration config = beanWriter.getBindingConfiguration();
config.setMapIDs(false);
beanWriter.enablePrettyPrint();
String declr = "<?xml version='1.0' encoding='UTF-8' ?>";
beanWriter.writeXmlDeclaration(declr);
beanWriter.write("mybean", bean);
beanWriter.flush();
beanWriter.close();
return null;
}
}
which when combined with this action mapping:
<action
path="/xml"
type="com.mycompany.web.actions.RESTAction"
name="xmlForm"
scope="request"
parameter="method"
validate="false">
<forward name="error" path="/WEB-INF/views/xml/error.jsp" />
</action>
is invoked like so:
http://myserver/myapp/xml?method=doSomething
I’m not 100% sold on this as the “way”, but I do like how simple Betwixt is. If you’ve got a different idea, comment away.
Tomcat 5.0.x bug with dollar sign (and non ASCII characters)
Hoping to bring this to the top of the queue for anyone else that runs into this: if you put configuration information into your Tomcat conf\server.xml file and said configuration contains a dollar sign ‘$’, according to bugzilla [1,2], the dollar sign is interpreted and thus doesn’t show up unless you double up on it. So if you have a environment entry like this:
<Environment name="ftp.password" type="java.lang.String" value="amsdk$k23"/>
you’ll need to change it to this:
<Environment name="ftp.password" type="java.lang.String" value="amsdk$$k23"/>
to make it work with Tomcat 5.0.x (same thing applies to JNDI entries in server.xml). According to this comment, this issue probably will not be fixed because Tomcat 5.0.x is in maintenance and not in active development. Supposedly this behavior will be fixed in version 5.5.7.
An observation: if you’re running a business selling software, make the bug list open the public. There’s nothing better than being able to find a solution without having to spend an hour on the phone with a technical support person who is doing nothing more than searching the private bug list.
Retrieving an RSS feed protected by Basic Authentication using ROME
Today I worked on a feature in a Struts web application where I needed to retrieve an RSS feed that is protected by Basic Authentication and then display the the results of the feed in a web page. I’ve heard alot about ROME in the past couple weeks, so I decided to try it out. It quickly passed the 10 minute test (downloaded rome-0.5.jar, downloaded jdom.jar, used the sample code from the tutorial on the wiki); I was able to retrieve, parse and display the results of my own feed in no time:
String feed = "http://cephas.net/blog/index.rdf";
URL feedUrl = new URL(feed);
SyndFeedInput input = new SyndFeedInput();
SyndFeed feed = input.build(new XmlReader(feedUrl));
System.out.println(feed);
Easy. But that wasn’t my problem. I needed to be able to set the Basic Authentication header which is usually done like this:
String feed = "http://yoursite.com/index.rdf";
URL feedUrl = new URL(feed)
HttpURLConnection httpcon = (HttpURLConnection)feedUrl.openConnection();
String encoding = new sun.misc.BASE64Encoder().
encode("username:password".getBytes());
httpcon.setRequestProperty ("Authorization", "Basic " + encoding);
httpcon.connect();
.. // do stuff
httpcon.disconnect();
Turns out that the designers of the ROME library were pretty smart. In addition to including the XmlReader(URL url) constructor, they also included a XmlReader(URLConnection connection) constructor, which allows you to combine the two blocks of code I wrote above to make this:
String feed = "http://yoursite.com/index.rdf";
URL feedUrl = new URL(feed)
HttpURLConnection httpcon = (HttpURLConnection)feedUrl.openConnection();
String encoding = new sun.misc.BASE64Encoder().
encode("username:password".getBytes());
httpcon.setRequestProperty ("Authorization", "Basic " + encoding);
SyndFeedInput input = new SyndFeedInput();
SyndFeed feed = input.build(new XmlReader(httpcon));
Add this code to your Struts action, put the resulting SyndFeed in the request scope (request.setAttribute("feed", feed);) and then in the JSP:
<c:forEach var="entry" items="${feed.entries}">
<strong>${entry.title}</strong><br />
${entry.description.value}<br />
<fmt:formatDate value="${entry.publishedDate}" type="both" pattern="MMMM dd, yyyy" />
by ${entry.author} | <a href="${entry.link}">link</a>
</c:forEach>
So there you have it. I hope that makes it easier for someone else!
dropcash and Java
If you’ve ever needed to raise a couple bucks for a project, a birthday or a fundraiser, you should check out dropcash (by Andre Torres). dropcash lets you set up a personal fundraising campaign using paypal and TypeKey. The campaign can be dropped into your site using a simple JavaScript include just like Flickr or Google Adsense, but you can programatically access the status of your campaign using the XML feed. There are a couple different implementations of the API (COM, MovableType, TextPattern and ColdFusion, more…), but no Java so I wrapped up a Java version and a JSP version. JSP is simpler of the two:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %>
<c:import var="dropcash" url="http://www.dropcash.com/campaign/ajohnson1200/test/xml"/>
<x:parse var="dropcashxml" doc="${dropcash}"/>
campaignid: <x:out select="$dropcashxml//@id" />
typekey_user: <x:out select="$dropcashxml//typekey_user"/>
receiver: <x:out select="$dropcashxml//receiver"/>
title: <x:out select="$dropcashxml//title"/>
goal: <x:out select="$dropcashxml//goal"/>
total_collected: <x:out select="$dropcashxml//total_collected"/>
description: <x:out select="$dropcashxml//description"/>
percentage: <x:out select="$dropcashxml//percentage"/>
Java less straightforward:
URL url = new URL("http://www.dropcash.com/campaign/ajohnson1200/test/xml");
HttpURLConnection uc = (HttpURLConnection)url.openConnection();
uc.connect();
InputStream is = uc.getInputStream();
DocumentBuilderFactory docfactory = DocumentBuilderFactory.newInstance();
InputStream inputXML = url.openStream();
DocumentBuilder docbuilder = docfactory.newDocumentBuilder();
Document document = docbuilder.parse(inputXML);
Element campaign = document.getDocumentElement();
System.out.println("campaignid = " + campaign.getAttribute("id"));
NodeList nodes = campaign.getChildNodes();
for (int i=0; i
Download the full JSP and Java source code.
Enjoy!
Automated Application Deployment with Tomcat: Part II with Subversion And Ant
Got around to writing the deployment scripts that go with the Subversion work I did last week. As part of the scripts, I also worked on the problem I wrote about a couple weeks ago (ie: needing different log4j properties files per environment). Once you have a source control solution and a master build file, it’s pretty easy. I stripped out the explicit log4j category and appender directives and instead used the Ant <propertyfile> tag to write out the appropriate category / appender directives based on the presence (or lack thereof) of the project.debug property in my build file. When I want to create a build that outputs logging information to the console, this block of code is fired:
<target name="build.resources.debug" if="project.debug">
<propertyfile
file="WEB-INF/classes/log4j.properties">
<entry key="log4j.rootCategory" value="INFO, STDOUT"/>
</propertyfile>
</target>
Otherwise, this block is run:
<target name="build.resources.production" unless="project.debug">
<propertyfile
file="WEB-INF/classes/log4j.properties">
<entry key="log4j.rootCategory" value="ERROR, SMTPAPPENDER"/>
<entry key="log4j.category.com.mycompany" value="ERROR, SMTPAPPENDER"/>
</propertyfile>
</target>
In Eclipse, you can easily create the project.debug property using the Arguments text box provided in Run –> External Tools –> $your ant build –> Main Tab –> Arguments: -Dproject.debug=true. By default then, log4j will only log error conditions and will send them to the SMTP appender.
The second thing I did was to create a deployment Ant script that wrapped my main build.xml. It checks out the source code from Subversion:
<exec executable="svn">
<arg line="co svn://sourcecodeserver/myproject/branches/v1.0 . --username username --password password"/>
</exec>
<ant antfile="build.xml" />
<exec executable="net">
<arg line='stop "Apache Tomcat"'/>
</exec>
<delete dir="${tomcat.install}myapp"/>
<mkdir dir="${tomcat.install}myapp"/>
<unzip src="myapp.war" dest="${tomcat.install}myapp"/>
<exec executable="net">
<arg line='start "Apache Tomcat"'/>
</exec>
We’ll see how well it works once this goes into production. If nothing else, at least I’ll have a couple more hours in my day.
Source Control with Subversion on Windows
We’re getting around to hiring an additional me at work so I needed to get a source control solution in place before he/she arrives and starts hacking away at the codebases. At the last place I worked we used Visual SourceSafe for a long time (which was pretty worthless) and then started using CVS, although not on the projects I worked on. A couple weeks ago I asked a bunch of questions about automating Java web application deployment and Erki suggested that I buy and read the Pragmatic Project Automation book, which I did and which I loved. I read it from start to finish (which isn’t an easy thing to do with a technical book) and took a ton of notes. Anyway, I’m pretty sure the book didn’t mention Subversion even once, but it did drill home the importance of setting up your code in source control and then doing your manual, scheduled, automated (using CruiseControl) or production builds directly from the source control system using Ant or Groovy, which led to alot of ideas about how you could automate builds to production Tomcat systems. I’ve heard alot about Subversion; it’s described as CVS with none of the warts and all of the features, so I tried it out. Following are the notes I kept during the installation process. Hopefully this helps out someone somewhere down the road:
a) Download Subversion (obviously) I downloaded version 1.1.1 ( svn-1.1.1-setup-2.exe)
b) Run the install. I chose to install to c:\subversion\.
c) Test the Subversion install by going to the install directory and then going to the /bin directory. Run the svnadmin from the command line:
CD c:\subversion\bin\
svnadmin
If you get an error that says that says “svnadmin.exe – Unable To Locate DLL”, you’ll need to either a) install the Visual C++ 6.0 VCREDIST.exe, which is available here (but only if you’re using Windows 98 or Windows ME) or b) find someone or some system that has msvcp60.dll and copy that file to c:\$windows\system32\ (where $windows is the directory that contains your Windows installation).
d) Create a repository on the machine that is going to host your source code. From the command line on the server machine:
svnadmin create d:\$projects\$projectname
where $projects is the name of a folder that will contain all your Subversion source code repositories and $projectname is the name of the specific project you’re going to create a repository for.
e) Start the server either from the command line:
svnserve -d -r d:\$projects
or use the SVN Service Wrapper (http://dark.clansoft.dk/~mbn/svnservice/), note that the r switch limits directory browsing by specifying the root of your repositories.
f) Create a users database (which is nothing more than a text file, I created a file called users.conf) and save it in the d:\$projects\$projectname\conf directory and then add your usernames & passwords. An example user database might look like this:[users]
aaron = mypassword
g) Within the d:\$projects\$projectname\directory, open the conf/svnserve.conf file using your text editor of choice and add the following to allow reading and writing to the users in the database we just created:
[general]
anon-access = none
auth-access = write
password-db = users.conf
realm = $projectname
where $projectname is the name of the project you’re setting up and users.conf is the name of the file you created in step f.
h) Finally, restart the server and you’re ready to start using the client and import your project.
i) To import an existing project, invoke the svn executable from the command line on the client:
svn import c:\temp\myproject svn://myserver/myproject -m "initial import" aaron mypassword
where c:\temp\myproject is the directory that contains the existing project you want to import (and should have 3 folders: trunk, tags and branches, your source code should be in the trunk folder; more on repository layout here), myserver is the name of the server that contains the Subversion repository you created in step d, myproject is the name of the project (ie: $projectname from step d) you’re importing into, the m switch signifies the message you want to tag this import with, followed by the username and password you setup in the users database in step f.
j) Finally, checkout the project from the server (invoking the svn executable from the directory that you want the trunk checked out from…, ie: c:\projects\myproject)
svn co svn://myserver/myproject/trunk . aaron mypassword
k) To add, move, delete, or edit and then commit any changes back to subversion:
Add: svn add src/myfile.java -m "adding a file"
Move: svn move src/myfile.java src/mynewfile.java -m "moved myfile.java to mynewfile.java"
Delete: svn delete src/myfile.java -m "removing a file"
Commit: svn commit src/myfile.java -m "the message"
That’s it… there’s a alot more to read. One of the coolest things about Subversion is that the documentation is all packaged up into a free PDF published by Oreilly, which you can download here. I printed out the manual and breezed through it in a couple hours. You should too.
I did try to get the Subclipse Eclipse Subversion plugin working, but for the life of me… I couldn’t. I think it ended up for the better anyhow because while the command line is a bit more tedious, I understand more about what’s going on in the system, which is helpful. I’d recommend that you get familiar with the command line client before attempting to use a GUI plugin.
After you’re all set with Subversion and you’re ready to get started with CruiseControl, note that while Cruisecontrol contains an <svn> tag, you still need to drop down into command line mode in Ant to checkout / update your local repository when doing an automated build. For example:
<exec executable="svn">
<arg line="update"/>
</exec>