From Eric: The Jakarta Commons HttpClient 2.0 Beta 1 was released on May 25. You can download the latest version here.

I’m using this library in the spider I’m writing, mainly because Larm uses it, so it must be good.

Update: A ResourceBundle object is the way to go. In comparison to the Properties class, the ResourceBundle class is a breeze. To load, read and retrieve the key ‘searchlib.dblibrary’ from a text file called ‘database.properties’ using the Properties class, you’d end up with something like this:

String databaseDriver;
try {
  FileInputStream propFile = new FileInputStream(“c:\\myapp\\sandbox\\database.properties”);
  Properties p = new Properties();
  p.load(propFile);
  databaseDriver = p.getProperty(“searchlib.dblibrary”);
} catch (java.io.FileNotFoundException fe) {}
} catch (java.io.IOException ie) {}

where you have to hardcode the path to the properties file and if the path changes, you have to recompile.

To do the same thing with the ResourceBundle class, you’d end up with something like this:

String databaseDriver;
ResourceBundle res = ResourceBundle.getBundle(“database”);
databaseDriver = res.getString(“searchlib.dblibrary”);

The file this time is located by JVM, located somewhere in the classpath. No try/catch is necessary. Alot easier isn’t it?

If you’re interested in reading more about the ResourceBundle class, check out this article on developer.java.sun.com:

Java Internationalization: Localization with ResourceBundles

I mentioned last night that I was attempting to use property files. So let’s say you have a class in a jar file that reads a property file and the property file is in the jar. Is there any way to load the property file without knowing exactly on the file system where the property file lives? Should I be using a ResourceBundle instead?

Oreilly has a Tomcat book coming out in June: Tomcat: The Definitive Guide. No table of contents yet…

Just me and the computers this weekend. I’ve not spent alot of time on IBM’s site, but developerWorks and alphaWorks (emerging technologies) are two really great sites. Not sure how often they update the site, but the Java technology directory on developerWorks has some nifty articles right now:

JDBC query logging made easy: “Add logging to your JDBC code with an enhanced PreparedStatement” This article shows you how you can implement the PreparedStatement interface, overriding default query behavior, to provide better debugging and logging facilities. I used PreparedStatements all over the place on karensrecipes.com, next rev I’ll be sure to add in a PreparedStatementLogging class. Also, the author mentions that the LoggableStatement class he’s written is a great example of the Decorator design pattern, which I wondering about a couple months ago.

Accessing SQL and XML content using JSTL: “Custom tag libraries for exchanging XML and database content in JSP pages” Looks like JSTL might be one or two revisions away from being as simple and easy to use as ColdFusion tags. Check out this JSTL SQL query example:

<sql:setDataSource var=”dataSrc”
    url=”jdbc:mysql:///taglib” driver=”org.gjt.mm.mysql.Driver”
    user=”admin” password=”secret”/>
    <sql:query var=”queryResults” dataSource=”${dataSrc}”>
  select * from blog group by created desc limit ?
  <sql:param value=”${6}”/></sql:query>

<table border=”1″>
  <tr>
    <th>ID</th>
    <th>Created</th>
    <th>Title</th>
    <th>Author</th>
  </tr>
<c:forEach var=”row” items=”${queryResults.rows}”>
  <tr>
    <td><c:out value=”${row.id}”/></td>
    <td><c:out value=”${row.created}”/></td>
    <td><c:out value=”${row.title}”/></td>
    <td><c:out value=”${row.author}”/></td>
  </tr>
</c:forEach>
</table>

Pretty close to a cfquery isn’t it?

Found this today in our developers meeting: The Java™ Specialists’ Newsletter Archive. Looks like a great resource. Sign up now.

Another version of the petstore application has been released, this one a re-implementation of the Sun Microsystem PetStore based on xDoclet. If you’re into learning more about EJB 2.0, CMP, CMR, Servlets, Web Filters and JSP TagLibs, then take a peek at the site.

Catching up on the homework for the free J2EE Programming Class I’m taking, this week drills down into the security options offered by servlet containers, specifically Tomcat. One of the things I hadn’t spent much time on before was the declarative security functionality that exists (apparently) in all servlet containers. Unlike ColdFusion and ASP, servlet containers (and thus Tomcat) give system administrators (not the developer) the ability to create password protected directories, ‘realms’ and users that access the directories within a specific realm. All the administration is done within the web.xml file of your web application. Here’s an example:

<web-app>
 <!– … –>
 <security-constraint>
   <web-resource-collection>
     <web-resource-name>Sensitive</web-resource-name>
     <url-pattern>/sensitive/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
     <role-name>administrator</role-name>
     <role-name>executive</role-name>
   </auth-constraint>
 </security-constraint>
 <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/login-error.html</form-error-page>
    </form-login-config>
 </login-config>
 <!– … –>
</web-app>

The above locks down the ‘/sensitive/’ directory (and everything inside it) to users in the administrative and executive realms and forces anyone and everyone trying to access said directory to login using /login.jsp.

Couple benefits that I see to this idea of declarative (rather than programmatic) security:

a) administration chores are handled by system administrators, no developer intervention is required outside of setting up the login pages.

b) According to this article, “.. J2EE compliant servlet containers are required to track authentication information at the container level (rather than at the web application level)” which means that if you setup multiple websites on a J2EE compliant servlet container, you get single sign on to all the applications running on that servlet container. Very cool.

c) Very little coding is required of programmers, giving them more time to focus on the applications they’re building, this also means fewer bugs.

Interested in reading more?

Declarative Web Application Security with Servlets and JSP: http://www.informit.com/isapi/product_id~%7B116C8D3F-BE60-47A3-B8EC-EF132654A5A3%7D/content/index.asp

Tomcat 4 Servlet/JSP Container Realm Configuration: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html

Tomcat 4 Single Sign On: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html

JRUN Security (no mention of any declarative security functionality): http://livedocs.macromedia.com/jrun4docs/JRun_Administrators_Guide/authentic.jsp

The JavaTM Web Services Tutorial: Web-Tier Security: http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebAppSecurity4.html