A while ago I worked for a bit on some Java servlet code which needed to talk to a MySQL backend database. Diverging a bit from my usual topics I thought I’d write this down in case it is useful for others (or at least it’ll be useful for me next time I need to do the same).

This configuration assumes Web Server 7. In server.xml I configured a JDBC resource for mysql:

  <jdbc-resource>
    <jndi-name>jdbc/mysql</jndi-name>
    <datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</datasource-class>
    <min-connections>1</min-connections>
    <max-connections>5</max-connections>
    <property>
      <name>password</name>
      <value>password-here</value>
    </property>
    <property>
      <name>user</name>
      <value>jyri</value>
    </property>
    <property>
      <name>url</name>
      <value>jdbc:mysql://boqueron/dbname</value>
    </property>
  </jdbc-resource>

Then I copied mysql-connector-java-3.1.12-bin.jar into $INSTANCE/lib (where $INSTANCE is the top level directory of the specific instance, note that you may need to create the lib directory there if it hasn’t been needed before).

In the web application itself, in web.xml, I configured:

 <resource-ref>
    <description>JDBC Connection Pool</description>
    <res-ref-name>jdbc/mysql</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

And in sun-web.xml:

  <resource-ref>
    <res-ref-name>jdbc/mysql</res-ref-name>
    <jndi-name>jdbc/mysql</jndi-name>
  </resource-ref>

That’s it for the configuration. In my servlet code:

    Context initContext = new InitialContext();
    Context webContext = (Context)initContext.lookup("java:/comp/env");

    DataSource ds = (DataSource) webContext.lookup("jdbc/mysql");
    Connection conn = ds.getConnection();

    Statement stmt = conn.createStatement();
     ....

Earlier I have coveredseveral different methods of approaching the problem of diagnosing HTTP (or even other protocol) traffic obscured within SSL/TLS.

There’s another approach that I haven’t mentioned yet which I use every now and then, whenever I want to look at what exactly the browser is sending. Check out tamperdata, a firefox extension which can alter the requests from the browser. While its main purpose is presumably to alter the data (which, as an aside, can be very useful for testing server and server application behavior in many ways) it can just as well be used merely for observing said data.

Of all the methods I’ve discussed this one is the most convenient as there is really nothing to do beyond installing the extension. Whenever you wish to observe the interaction just open the tamperdata window (from Tools menu) and watch away. The limitation, of course, is that it’s only good for watching interaction originating from your single browser session. But often that is all you need.

Every now and then I get requests on how to load one or more CRLs (Certificate Revocation List) into the web server without going through the admin GUI (in 6.1, only the GUI has direct support for updating CRLs). Clearly this is a useful goal since going through the GUI would require manual intervention, hardly practical for most web servers.

It is possible to do this in 6.1 via crlutil. However, there’s a potentially big catch – it is necessary to restart the server instance(s) to pick up the new CRL(s). Depending on how often the CRLs are refreshed, how many CA (Certificate Authority) CRLs need to be refreshed and the site’s uptime requirements, this can be a problem.

One of the many nice features of 7.0 (preview here) is that it allows CRLs to be loaded dynamically at runtime.

Every server instance can define a directory from where CRLs will be loaded, as follows, in server.xml (if you have multiple instances you’ll most likely want to share this location amongst them):

  <pkcs11>
     <crl-path>/export/crls</crl-path>
  </pkcs11>

7.0 also introduces a mechanism for running recurring events. This can be used (among other things – but a full description is a topic for another time) to refresh the CRLs. The following will check every minute (60 seconds) to see if any new CRLs are available:

  <event>
    <interval>60</interval>
    <update-crl/>
  </event>

And that’s all there is to it. You can copy new CRLs as they become available into your crl-path and the server will pick them up automatically. I recommend setting up a simple script which will obtain the new CRLs from your CA periodically and copy them into crl-path; you can call this from cron at desired intervals. Also look into the <time> element within <event>, it can be a better fit if you set up refreshes at fixed times.

As a side note, while experimenting with WS 7.0 configuration it is handy to edit server.xml manually. However, if you end up wanting to automate configuring your instances, always go through wadm instead. You definitely don’t want to do something fragile like writing perl scripts to directly manipulate server.xml – such code is likely to break when you upgrade to a future version of the server. Instead, write scripts around wadm. That way wadm will shield your code from any internal configuration changes. In that spirit, take a look at the following wadm commands: list-crl, install-crl, delete-crl, get-crl-prop, list-events, create-event, delete-event, get-event-prop, enable-event, disable-event.

An exciting week in the land of web server – if you’ve visited our Java One booth or been following the blog you already know that a preview of Sun’s JES Web Server 7.0 is now available for you to download.

7.0 is a new Major release and there is quite a bit new and improved indeed. If you are used to operating through the admin GUI the major change you will notice very quickly is the all-new admin.

On the other hand, if you’re the type to go looking at the actual installation, the major change you’ll notice right away is that the file layout is quite a bit different from previous releases.

Let me digress for a moment… One of my jobs here at Sun is as a member of Sun’s ARC (Architecture Review Committee). John Plocher has written to some length about Sun’s ARC process so I won’t repeat too much of that. One of the many goals of the ARC process is to make sure there is clarity as to which interfaces customers can rely on.

As long as you rely only on public Stable interfaces you will be assured that your code will continue to work in future releases (this is why you can take binaries you might’ve compiled on Solaris over 10 years ago and they still run on Solaris 10!). If, however, you build a dependency on any undocumented (private) interface, you must assume your code will break at any time without warning (usually at the worst possible time). Clearly, not a good idea.

(Please note that the word interface is used in a very broad sense. Anything you might depend on is an interface. APIs are interfaces, but so are CLI names and options, file locations, some output and so forth. Anything you might be able to build a dependency on can be an interface. Note also that Stable interfaces may in some cases also change – but only in Major releases with advance notice, so you’d have plenty of time to adjust.)

Why do I bring this up? Well, I’ll give a quick view of the file layout changes in 7.0 and I’ll also say a bit about where things fall with respect to their interface classification.

The web server file layout up to 6.1 harks back to the old iPlanet days and it had grown a bit messy over the years. In 7.0 things have been reorganized and cleaned up. Also, the layout makes it a bit easier for you to identify what you can rely on and what is off-limits.

If you look at the top-level installation directory here are a few important areas to note:

That’s the quick tour of the 7.0 file layout (I didn’t cover every detail here, but enough to get you started). Download the bits and play with them to see what else is new.

I should point out that while the interface details I’ve given here are unlikely to change significantly from now until the product is released, they may of course change. The current preview build is just a preview, after all, still subject to change. For the same reason, I didn’t write down precise interface levels, just a general description of each area. The formal product documentation which will be available when the production releasecomes out will contain the authoritative interface information.

RFC 4492 has just recently been released, covering ECC support in TLS. A timely coincidence, given today’s announcement of the JES Web Server 7 technology preview availability, containing the ECC support I’ve talked about earlier.