Tuesday May 23, 2006
Jyri Virkki
A Week Of Web Server 7
Well, today it is a week since the release of the Web Server 7 Technology Preview at Java One and things have been pretty busy. We're getting good interest and feedback on it. Have you tried it yet?
I've also seen quite a few blog entries from other members of my team on all the new features. I encourage you to read through them to get a feel of what is available. Check out my list of bookmarks on the right for links to them.
Posted at 11:24PM May 23, 2006 by jyri in WebServer |
Using MySQL with Web Server 7
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();
....
Posted at 04:14PM May 22, 2006 by jyri in WebServer |
More on Observing SSL Requests
Earlier I have covered several 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.
Posted at 10:56PM May 19, 2006 by jyri in WebServer |
Dynamic CRL Updates in Web Server 7.0
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.
Posted at 06:42AM May 18, 2006 by jyri in WebServer | Comments[2]
A Peek Into Web Server 7.0 Files
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:
| Directory | Comments |
|---|---|
| bin | This contains public binaries you can rely on. You can build shell or other scripts using the commands you find here. |
| include | This is a public directory containing include files you may need when compiling code for use with the server. |
| plugins | This is also a public directory, containing plugins you may interact with directly. |
| samples | Here are code samples that demonstrate use of various features. While this is (of course!) public for you to use, note that samples are Unstable (which makes sense - the purpose of samples is to showcase features, not to be relied on as-is). |
| admin-server | Unlike 6.1 where the admin server instance was named with the same pattern as regular instances, in 7.0 the admin server is always under this directory. Within admin-server, you can access the scripts in bin and the files in logs. Other subdirectories contain private implementation detail only. |
| https-* | These are the server instances. As with admin-server, the bin and logs
subdirectories are public. Unlike 6.1, the docs (default docroot)
is unique to each instance and can be found here. Another major
cleanup from 6.1 is that all the instance configuration lives in
one place within the config directory - no more hunting for instance
configuration among many top-level directories!
An important note about configuration files: while you may edit these manually with emacs (or lesser editors ;-), do not establish programmatic dependencies (e.g. sed scripts) on these. For scripting changes, go through wadm, the all-new CLI included in 7.0. By doing this you will isolate your scripts from any future config file format changes. |
| lib | This is a private directory. Its contents are not available for direct consumption, it only contains private implementation detail. |
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 release comes out will contain the authoritative interface information.
Posted at 06:30AM May 17, 2006 by jyri in WebServer |
ECC TLS RFC Released
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.
Posted at 03:44PM May 16, 2006 by jyri in WebServer |
Web Server 7.0 at Java One 2006
In case you missed some of the other entries about it, be sure to visit the web server team at Java One so you can check out a preview of the latest 7.0 release!
I had earlier mentioned the ECC support being introduced in 7.0, but there is a lot more to look forward to in this release. Stop by, ask some questions.
Posted at 06:18PM May 15, 2006 by jyri in WebServer |