Technorati Tags: edburns

The ever resourceful and "do-the-right-thing"ful Ryan Lubke has started a series of blog entries showing how to use some JSF 2.0 features. Not all of the below features are showcased in Ryan's blog just yet, but here's a look at what's coming in what's coming (how's that for cutting edge!)

Speaking of cutting edge, if you want to find out how today's top programmers stay that way, check out my new book, Secrets of the Rockstar Programmers from McGraw-Hill, available in stores in March.

• Ajax. Tracked at issue 293.

  We finally have a solution to the thorny, "my component needs a resource (script, stylesheet, image), it needs to be in the HEAD (or body, or form), but I'm not in the HEAD (or body or correct form). Can you please just 'do the right thing' for me?"

  We've decided there will be a top level ajax.js file and that this file will contain the standard JSF 2.0 JavaScript API. We haven't established what will be in this API, but it will have the following attributes:

  • In a page that uses JSF, there must be a top level JavaScript object named "javax", whose type is a JavaScript associative array. We've undertaken the necessary communication with the Open Ajax Alliance, and their Hub concept to reserve the "javax" namespace.

  • Within that top level JavaScript object, found in the OpenAjax Hub, there will be a "faces" property, whose value must be another JavaScript associative array.

  • Within the "faces" JavaScript object, there will be yet another JavaScript associative array, under the key "Ajax".

  • This JavaScript associative array, will have properties that are the JavaScript functions that comprise the JSF 2.0 JavaScript API

  • If any components in the page declare they require the JSF 2.0 JavaScript API, the runtime must guarantee that the ajax.js file is delivered to the client and that this file satisfies the above conditions.

  We're working to finalize spec details on the above items before proceeding with fleshing out the actual JSF 2.0 JavaScript API. I'm certain it will include JavaScript functions for:

  • Partial page refresh via ajax

  • Partial page update via ajax

  • Given a jsf componentId or clientId, give me the client DOM Element that corresponds to the outermost markup for that component.

  • Give me the JSF View State that would be sent in a POSTBACK or Ajax request.

• EZComp. Tracked at issue 273.

  This one has stalled a bit due to Ajax. However, one aspect that has proceeded is MegaListeners. Once we have this checked in, look to Ryan Lubke's Blog <http://blogs.sun.com/rlubke/> for tips on how to use it.

  Two more features of note are the new view scope, and the RAILS_ENV.

Leaving Oracle aside, there were some other glaring omissions from the web 2.0 space. Neither Yahoo! nor Facebook participated. Were they invited? Won't people want to use Flickr based apps on their chosen social platform? Finally, if you want to call something open, there's usually some sort of governancy body that ensures the stakeholders are equally represented (for some definition of "equal").

The Job of the JCP Spec Lead

I'd like to contrast this with the (admittedly much smaller) world of the Java Community Process (JCP) and my (smaller still) view of it as the co-spec lead of the JavaServer Faces (JSF) 2.0 Expert Group (EG).

At the beginning of October I received an email from JSF stake holder and JBoss representative Gavin King. Gavin had some concerns about how I had been running the JSR. Chief among them was his concern that the important voices in the JSF community were not being herd on the EG. While I respectfully disagreed about that being the case, I agreed to make some changes to address his concerns.

One such change was to delegate the initial design work for our top priority issue for JSF 2.0 to JSF stake holder and Facelets creator Jacob Hookom. Jacob shared his initial sketch with the EG today and immediately we had useful constructive feedback from Ken Paulsen, creator of JSFTemplating, and Gary VanMatre, creator of Apache Shale Clay. That means all of the major templating languages for JSF are actively contributing to JSF 2.0. That's JCP at its best.

Graphical Indicators of JSF Usage

From time to time, the JSF team at Sun surfs around a bit looking for new Internet sites using JSF. This time, my colleague Roger Kitain discovered that Virgin Megastore is a JSF User.

Within Sun, we have an elevator pitch-like slide deck about JSF, and the most important slide therein is at the left. If you want more details about the sites pictured, or you want to add some more sites to the list using JSF, the wiki page is <http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks>.

By way of update on JSF 2.0, Jacob Hookom, the developer of Facelets and JSF Expert Group member, is leading the drive toward our number one goal for JSF 2.0: Making custom components easier to develop. We're expecting an EG-private proposal from Jacob this week. Once we get it firmed up we'll share it publically in an Early Draft Review of the spec. In other JSF 2.0 news, we have provisionally closed on the issue of resource loading, as listed in [115-CompResources]. This will also be in the EDR.

Credit Suisse is the largest financial institution to go public with its investment in JSF, though I have it on good authority that Deutsche Bank, and Oesterreichische Kontrollbank also have made significant investments in JSF. Mr. Jesse's presentation at Jazoon detailed how Credit Suisse has achieved significant advances in developer productivity, UI uniformity, and maintainability by creating a custom JSF component library specific to the needs of Credit Suisse IT developers. Mr. Jesse printed up flyers announcing the JSF user group meeting and these were distributed in the Sun and Credit Suisse booths in the exhibitor area, as well as at every one of the five JSF related presentations at Jazoon.

The primary goals of this inaugural meeting was to decide if there was a need for a JSF user group in Switzerland, should the group be a special interest group (SIG) within JUGs or a standalone group, and how often should the group meet. Secondarily, Mr. Jesse and I would present some fun technical content, not found anywhere else at Jazoon.

The slides from the meeting can be found here:

• Scripting JSF

• JSF 2.0

• Alexander Jesse Slides JSF, Quo Vadis (in German)

We had about 22 people attending the meeting, about half of whom had heard of it from the conference. The response was enthusiastic. Alexander's notes from the meeting can be found at his blog, at <http://ajesse.wordpress.com/2007/07/12/jsf-usergroup-ch-meeting-1/>.

Please leave a comment on this blog if you're interested in the next meeting.

As we're starting up JSF 2.0 I'll keep this runtime backwards compatibility firmly in mind as I corral debate and discussion on new features.

To complete this exercise, we used one of Luke Hohmann's Innovation Games: Buy a Feature. From Luke's description:

Create a list of features with an estimated cost. The cost can be development effort or something else; although the cost can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release. Make certain that some features are priced high enough that no one customer can buy them. This will help motivate negotiations between customers as to which features are most important. Encourage customers to pool their money to buy especially important / expensive features. Works best with 4-5 customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.

"Buy a Feature" is just one of the great games in Luke's book, Innovation Games: Creating Breakthrough Products Through Collaborative Play .

Exercising spec lead authority, I looked at 1) the JSR draft, 2) the Requirements Scratchpad, and 3) Alex Smirnov's requirements document, and picked 15 requirements using a weighting algorithm. I assigned prices to each based on how much spec effort I thought it would take to specify each feature. I took the final 15 into the meeting. JCP Experts being JCP Experts, there was some disagreement over my inclusions and omissions from the list. I pushed aside this disagreement, for the most part, and only allowed two changes to the menu at the meeting. The actual menu used at the meeting follows.

Playing the Game

We broke down into groups of four, and Roger Kitain, Dennis Byrne and I played the role of feature retailers. Dennis Byrne, who works for world-famous XP Consulting firm ThoughtWorks remarked that his firm uses similar techniques to discover the preferences of clients. From his experience in playing such games, he was very pleased with the amount of high quality discussion in the groups, and so was I. These people clearly had strong opinions about web application frameworks, but at the same time were professional in sharing them. The collaboration aspect of the game was a success, which in itself is a good outcome to a JCP Expert Group kick-off meeting.

After each of the four groups had completed their shopping, I collected the results which are summarized in the following table.

Conclusion

There were some problems with the exercise. Ever the inveterate gamer, Howard Lewis-Ship pointed out (sadly, after the exercise was complete) that we had given too much money to each individual, which under-constrained the participants and thus masked their true feelings. This was an honest miscalculation, which I deeply regret. In addition, participants complained of a lack of consistent level of detail among the menu items. Some were very low level and specific, others high level and generic. This required each group to re-define the generic items for their own purposes, and naturally each one did it in their own way. Each menu item was not cleanly disjoint from all the others, leading to a participant to have to choose between items that both possesed some of what they were looking for. In spite of these problems, I consider the exercise a success, for the experience in playing it for future meetings, and, to a lesser extent, for the hard data produced.

Postscript

Finally, I was delighted to have bumped into Jonathan Schwartz in the halls of the Sun building where the meeting was being held. Having known Jonathan from my days at Lighthouse Design, and knowing that deeply understands developers, I felt confident in asking him to stop by the meeting and thank the EG members for donating their time to the Java Community Process. He went one step further and hung out for a little bit collecting data on how well the EG members felt the JCP was working.

Attendees

To make this easy, I've recorded an Elluminate screencast showing MCP in action testing the Dynamic Faces and jMaki sample application. If you're a Sun employee and you choose not to view this screencast just because I'm making you use JavaWebStart to view it, please tell me so I can report you to the "eating our own dogfood" police.

To view the screencast, click here.

If you want to go even deeper into shaping JSF 2.0 and the JSR submission, you can view and edit the wiki for a JSF 2.0 Requirements Scratchpad document. When the JSR gets rolling, the requirements in that document will be turned into issues in the JavaServer Faces Specification Issue Tracker.

Finally, I'd like to take this opportunity to extend an invitation to several individuals outside of the JSF community to join us in developing the next version of the Java standard web application framework. Specifically, I call upon Howard Lewis-Ship, Geert Bevin, Eelco Hillenius, and Tim Fennell to consider Joining the JCP so they can join the Expert Group when it forms. Of course, there are many other folks whose expertise would be appreciated on the Expert Group, but Howard, Geert, Eelco and Tim come to mind because each of them has their own web framework outside of JSF.

Please let us know what you think about starting JSF 2.0!

public native Element getElementById(String elementId);

into this:

public Element getElementById(String elementId) {
  // Make this happen on the NativeEventThread.
  return nativeGetElementById(elementId);
}
native Element nativeGetElementById(String elementId);

Of course, I would have to modify the function names in the native C++ source files as well.

In case you were wondering, I did consider these solutions but rejected them.

Use Javier Pedemonte's Java XPCOM bridge

I plan to completely rewrite the mozilla layer of webclient and dom to use this most excellent software after I get the 2.0 release done. I don't have time for that extensive rewrite now.

Use aspect oriented programming techniques

Sure, I could do this, but I don't want to introduce another dependency on another technology.

That said, I wrote some xemacs macros as I went along and it only took a couple hours of manual editing. While doing it, I re-compiled all along the way. Naturally, the compiler caught some things, which I easily fixed, as I went along.

This got me thinking. Say this code was written entirely in a scripting language. If so, this sort of "complicated, human-assisted global search and replace" change (I won't call it refactoring since this particular process was so specific to JNI) would be really error prone and hard to debug. The absence of a type checking compiler would really make this sort of change hard.

I assert that this sort of change is happens all the time in the maintenance phase of a large software project. I assert that the person making the change is seldom the same person who wrote the code originally. Given these assertions, I predict much woe for the maintenance programmer who has to do such a change on a scripting language based project. I continue to urge caution for those listening to scripting zealots when they consider moving more of their projects to scripting languages.

Now that over a year has passed, I thought it would be fun to throw in a graph. Here is a chart of the daily log size for the ##jsf channel, where each data point is a weekly average of the size, in bytes, of the daily log file. The first datapoint in the x axis is from the fourth week of 2006, on up to today.

If you want to join the channel, please see the instructions at the JSF main site.

Many thanks to Geert Bevin who, very graciously and professionally provides the log bot on the channel.

Background and History

If you've read my blog before, you know that I think JSF is a good fit for handling the motherhood and apple pie requirements of web applications. What you may not know is that jMaki intentionally leaves the work of satisfying these requirements as an exercise for the developer. No problem, just use jMaki and JSF together. This is indeed a valid answer, but there is a subtlety that bears clarification.

When using jMaki + JSF under J2EE 1.4 (the default target audience for jMaki), you miss out on the following features:

• Ability to have the jMaki widget POST back to the faces page while preserving the JSF view state.

• Ability to use jMaki widgets that represent components that accept user input within an iterating component such as dataTable.

• Ability to attach valueChangeListeners to jMaki components in the view.

• Ability to attach converters and validators to jMaki components in the view.

• Ability to attach action and/or actionListeners to jMaki components in the view.

These deficiencies stem both from missing features in the built-in jMaki JSF support and from missing features in JSF 1.1 commonly used with J2EE 1.4.

The story about jMaki and Dynamic Faces

By using jMaki with Dynamic Faces on top of JavaEE 5, however, all of these deficiencies can be addressed (with the exception of the last two, and issues have been filed for these features). This section discusses how using jMaki and Dynamic Faces addresses all of the deficiencies mentioned above.

Ability to have the jMaki widget POST back to the faces page while preserving the JSF view state.

This is the big one, and it was at the heart of the JavaOne presentation in which I participated. The lack of this feature in many Ajax + JSF solutions is what prompted us to title the session, "Ajax done right". When you do not have the JSF view state, you cannot do any of the things that JSF does well. Including the JSF View state in the Ajax transaction is essential.

By using Dynamic Faces to send and receive Ajax transactions from the browser to the JSF view, the JSF view state is correctly preserved, allowing the entire JSF lifecycle to be used, including conversion, validation, events, etc.

Ability to use jMaki widgets that represent components that accept user input within an iterating component such as dataTable.

This one is near and dear to Jacob Hookom's heart. Not only do you need the JSF view state, but you need a way to apply individual values to an individual components within a composite component (such as a table or tree). This capability did not exist in JSF until version 1.2, and Dynamic Faces takes full advantage of it.

Ability to attach valueChangeListeners to jMaki components in the view.

This didn't exist in jMaki until issue 3 was fixed. However, even though you can add a valueChangeListener to a jMaki component now, you still need to preserve the JSF view state in order for it to ever have a chance of being invoked. Again, Dynamic Faces is the answer.

Ability to attach converters and validators to jMaki components in the view.

Ability to attach action and/or actionListeners to g jMaki components in the view.

As with valueChangeListener, these two need to be first implemented in jMaki, then they need to be used with Dynamic Faces.

How To

The whole point of jMaki is to put today's hot JavaScript widget libraries in the hands of Java web application developers. Each widget library has different ways of doing things, and indeed, each widget within each library does too. jMaki solves this by having specific files with each widget. Therefore, adding Dynamic Faces support to each widget involves making some modifications to the widget specific files. Currently, the only widgets that have been modified are the Dojo FishEye and Inline Editor, and the Scriptaculous Inplace Editor. This section shows some high level guidelines for how to add Dynamic Faces support to an arbitrary jMaki widget.

The widget specific files for a jMaki widget are:

In general, you'll probably just need to modify component.js to add Dynamic Faces support. Please follow Jennifer's Tutorial for how to get started with jMaki and Dynamic Faces. Once you've done that, you need to make sure to include the Dynamic Faces taglib and script tag in the page on which you are using the jMaki widgets.

Syntax highlighting courtesy of http://www.nopaste.com/.

Listing 1, the JSP Page

<%@ taglib prefix="a" uri="http://java.sun.com/jmaki-jsf" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib prefix="jsfExt" uri="http://java.sun.com/jsf/extensions/dynafaces"%> 
 
<h2>Editor Using JSF</h2>
<hr>
 
<f:view>
 
<jsfExt:scripts />
 
<h:form prependId="false">
  <h:dataTable id="table" rows="10" binding="#{ResultSetBean.data}"
               value="#{ResultSetBean.list}" var="customer">
 
    <h:column>
      <f:facet           name="header">
        <h:outputText  value="Account Id"/>
      </f:facet>
      <h:outputText        id="accountId"
                     value="#{customer.accountId}"/>
    </h:column>
 
    <h:column>
      <f:facet           name="header">
        <h:outputText  value="Customer Name"/>
      </f:facet>
 <a:ajax name="dojo.inlineedit" value="#{customer.name}" />
    </h:column>
 
    <h:column>
      <f:facet           name="header">
        <h:outputText  value="Symbol"/>
      </f:facet>
      <h:outputText        id="symbol"
                     value="#{customer.symbol}"/>
    </h:column>
 
    <h:column>
      <f:facet           name="header">
        <h:outputText  value="Total Sales"/>
      </f:facet>
      <h:outputText       id="totalSales"
                     value="#{customer.totalSales}"/>
    </h:column>
 
  </h:dataTable>
 
</h:form>
 
</f:view>
 

Line 4 has the taglib for Dynamic Faces, line 11 uses the scripts tag. Line 29 has the use of the jMaki ajax component.

Let's take a look at the component.js for the Dojo Inline Edit widget, before Dynamic Faces support was added.

Listing 2, the component.js before Dynamic Faces is added

dojo.require("dojo.widget.*");
dojo.require("dojo.widget.InlineEditBox");
dojo.require("dojo.event.*");
 
var container = document.getElementById(widget.uuid);
var w = dojo.widget.createWidget(container);
 
w.getValue = function() {
    return w.textValue;
}
 
// add a saveState function
if (typeof widget.valueCallback != 'undefined') {
    w.onSave = function(newValue, oldValue) {   
        // we need to be able to adjust this
        var url = widget.valueCallback;
        dojo.io.bind({
                url: url + "?cmd=update",
                method: "post",
            content: { "value" : newValue  },
            load: function (type,data,evt) {
                // do something if there is an error
            }
        });
    }
}
w.saveState = w.onSave;
jmaki.attributes.put(widget.uuid, w);

On lines 1 - 3 we have the dojo includes: uninteresting. Line 5 of listing 2 is interesting. The "widget" refererred to is this instance of this widget in the page. In this case, it's the widget on line 29 of Listing 1. However, keep in mind that line 29 of listing 1 is inside of a dataTable, therefore, there will be 10 instances of this widget in the page, each corresponding to an actual JavaScript object in the JavaScript VM. Therefore, the value of widget.uuid will be different for each widget, and will, most importantly, correspond to the JSF Client Id for the widget in the JSF view. This is important because in order to address the widget in the JSF view, you need its client id.

For example, the widget.uuid values for this page happen to be table:n:j_id_id34 where n is the numbers 0 to 9.

Returning to line 5 of listing 2, the actual DOM element returned by the call to document.getElementById is what jMaki renders based on the content of the component.htm file. For the dojo inline editor, this file is:

<div id="${uuid}" dojoType="inlineEditBox" class="dInlineEdit">${value}</div>

The jMaki AjaxWrapperRenderer will cause the component.htm file to be rendered like this in the page from listing 1.

<div id="table:0:j_id_id34" dojoType="inlineEditBox" class="dInlineEdit">name_0</div>

Therefore, when line 5 of listing 2 executes, the value of container is the div element with id table:n:j_id_id34, where n, of course, is the current row in the table.

Line 6 of listing 2 uses the dojo createWidget to create an instance of the inline edit box inside of the container element.

Lines 14 - 25 of listing 2 declares the JavaScript function that will be called when the user presses the "save" button in the widget UI.

Now, let's take a look at the changes to component.js necessary to add Dynamic Faces support, expressed as a diff.

Listing 3, the diffs to component.js to add Dynamic Faces support

--- component-pre-DF.js	2006-12-07 10:32:25.000000000 -0500
+++ component.js	2006-12-07 10:31:19.000000000 -0500
@@ -12,6 +12,16 @@
 // add a saveState function
 if (typeof widget.valueCallback != 'undefined') {
     w.onSave = function(newValue, oldValue) {   
+
+      if (typeof _globalScope.DynaFaces != 'undefined') {
+	  DynaFaces.fireAjaxTransaction(container, 
+					{
+					execute: widget.uuid,
+					render: "none",
+					postBody: widget.uuid + "=" + newValue
+					});
+      }
+      else {
         // we need to be able to adjust this
         var url = widget.valueCallback;
         dojo.io.bind({
@@ -22,7 +32,8 @@
                 // do something if there is an error
             }
         });
+      }
     }
 }
 w.saveState = w.onSave;
-jmaki.attributes.put(widget.uuid, w);
\ No newline at end of file
+jmaki.attributes.put(widget.uuid, w);

The only change is a conditional within the onSave function. jMaki defines a _globalScope global variable that allows you to access all things globally defined in the page. It so happens that the scripts included by virtue of line 11 of listing 1 define a global variable called DynaFaces. This JavaScript object has all the functions exposed by the Dynamic Faces JavaScript library. Therefore, you can safely test for the existing of Dynamic Faces in a page as shown on line 8 of listing 3. If Dynamic faces is not being used in the page, then the normal jMaki operation of the widget takes place, as shown on lines 17 - 23 of the diff.

Lines 9 - 14 of listing 3 cause a Dynamic Faces Ajax transaction to be made back to the JSF page currently being viewed in the browser. This transaction includes all the view state for the current f:view. The first argument to fireAjaxTransaction is the DOM element from which the transaction should be fired. It is important that this be the DOM element that corresponds to the actual JSF UIComponent in the view. The second argument to fireAjaxTransaction is a JavaScript associative array. In this case, we're saying three things:

• do the 'execute' portion of the JSF lifecycle just on the JSF UIComponent for this widget instance.

• do not re-render anything to the browser (in this case, Dojo handles it).

• In the HTTP POST body of the request, include the name value pair for the currently entered value of the widget.

Note that newValue, on line 6 of listing 3, is an argument to the onSave function. It is the new value entered by the user.

For more information on the JavaScript functions exposed from Dynamic Faces, see the Dynamic Faces Reference.

Summary

jMaki gives you cool widgets. Dynamic Faces + jMaki gives you cool widgets you can use in a real enterprise web application.

I had been doing the multi-boot thing on my Toshiba Satellite 5205-S703 since I bought it in late 2002. It came factory installed with Windows XP Home Edition (monopoly anyone?) on an NTFS partition. Thanks to Partition Magic 7.0, I soon ended up with the following partition table:

Physical Geometry: 7,926 Cyls, 255 Hds, 63, Sects

Drive: C:
Partition Type: 07 (Hex) NTFS
Serial Number: F8CD:F94F
Total Physical Sectors: 80,080,632 (3,945.6 MB)

Drive: E:
Partition Type: 08 (Hex) FAT32
Serial Number: None
Total Physical Sectors: 8,353,800 (4,079.0 MB)

Drive: Extended
Partition Type: 0F (Hex) ExtendedX
Serial Number: None
Total Physical Sectors: 100,775,745 (49,206.9 MB)

Drive: F:
Partition Type: 08 (Hex) FAT32
Serial Number: None
Total Physical Sectors: 78,605,982 (38,381.8 MB)

Drive:  SWAPSPACE2
Partition Type: 82 (Hex) Linux Swap
Serial Number: None
Total Physical Sectors: 2,120,517 (1,035.4 MB)

Drive: Linux Ext2
Partition Type: 83 (Hex) Linux Ext2
Serial Number: None
Total Physical Sectors: 20,049,057 (9,789.6 MB) 

C: contained the factory Windows XP, E: contained Windows 2000 Professional, where I did most of my production work, including work on mozilla.org side projects. In the GNU/Linux partition, I ran Sun Java Desktop System Linux. I used GRUB as my bootloader, but somehow managed to have the Windows bootloader in there as well (like a sub-menu) to choose between Win XP and 2k, once "Windows" had been chosen from the main menu. I never bothered to fix that.

At the JAOO 2006 conference, VMware was giving out free licenses to their VMware workstation 5.5 product. Seeing an opportunity to free myself from the shackles of a multi-boot existence, I took one. Several months later, I began the long and arduous process of converting my multi-boot machine into one that just boots the factory installed OS (since that's the only thing officially supported by the manufacturer anyway) and uses VMs for the other OSes.

Process

I wanted to convert the OSes installed in my real hard disk partitions into VMs. Here is the high level process I will use.

1. Install VMware Workstation 5.5 under the Windows XP OS, using an external disk for extra space and to contain the VMs for the guest OSes.

2. For each OS on a real partition on my disk

   1. Use a Knoppix 3.7 CD I had made years ago to boot the Toshiba laptop. Once booted into Knoppix, use partimage to create partition images of all the OS partitions on the mahcine. Swap partitions needn't be imaged, for obvious reasons, and data partitions needn't be imaged because they can simply be copied. I stored the partimage files on an external disk.

   2. Create a VM for that OS, storing it on an external disk.

   3. Boot the VM into Knoppix

   4. Install VMware tools into the running Knoppix instance so I can access the partimage files using the "shared folders" feature of VMware.

   5. Use partimage to restore the OS partition into the virtual hard disk of the VM.

   6. Re-install the appropriate boot loader for that OS to enable that OS to boot.

3. Once VMs had been created, on an external disk, for all the OSes on real partitions, completely and totally wipe, defrag, and re-install from factory media the laptop. After the factory restore has completed, run Windows update however many times I need to get the machine totally up to snuff and current. Re-install virus protection software and other essential goodies. Note, on the core, non virtual OS, I plan to install very little real software, just stuff that absolutely has to have access to the real hardware.

Details for the hard part: Steps b. thru f. above

1. Create the new VM using VMware.

   Set the guest OS type to be the type of the OS stored in your partimage files.

   Make sure the hard drive types (IDE or SCSI) match what is in the partimage files. I chose to pre-allocate space. Not sure if this is necessary.

   Make the same amount of disk space is allocated in the VM as was in the partition from which the partimage files were made.

   Because you are using the Knoppix live CD, you need to mount a second CDROM drive from the linux.iso file, located in the install directory of VMware. Make sure to assign IDE 1.1 to this virtual CDROM drive.

   Use the VMware shared folders feature to expose your partimage files to the VM.

2. Boot knoppix and install VMware tools into the running Knoppix instance.

   Download the vmware-knoppix-overlay.tar.gz to a real machine on which an FTP server is running. In fact, this can be the VMware host machine, but it needn't be.

   With the Knoppix CD in the drive, start the VM, pressing escape during the VMware startup screen to enter the boot menu. Select CDROM.

   When Knoppix starts up, get root access: su - , then

   cd /tmp
   tar -zxf /mnt/cdrom1/VMwareTools-5.5.3-34685.tar.gz
   

   Use FTP to transfer the vmware-knoppix-overlay.tar.gz file to /tmp in Knoppix.

   cd /
   tar -zxf /tmp/vmware-knoppix-overlay.tar.gz
   cd /tmp/vmware-tools-distrib
   ./vmware-install.pl
   

   This will run the modified VMware installer for Knoppix. When it asks "In which directory do you want to install the binary files?" answer /ramdisk/bin.

   Accept the defaults for the rest of the questions until it asks, "What is the location of the directory of C header files that match your running kernel?" Answer /ramdisk/lib/modules/2.4.27/build/include.

   When done with these scripts, you should have access to your shared folders under the path /mnt/hgfs.

3. Use fdisk under knoppix to partition the virtual disk, most likely it will be /dev/hda, in such a way that it is equivalent to the partimage files you are going to restore. For example, if the partimage files were created from a JFS filesystem, use JFS as the partition type in fdisk. If you need to create a swap partition, make sure to do that as well.

4. Use partimage to restore the image files under /mnt/hgfs to the new virtual disk.

5. Lastly, you need to make sure that the boot loader has been restored. It's very unlikely that you can use the bootloader that happened to be installed in the partimage files. Of course, bootloaders are a matter of preference, but I used GRUB. Here's what I had to do in my case.

   Back at the root prompt in Knoppix:

   mkdir /mnt/hda1
   mount /dev/hda1 /mnt/hda1
   cd /mnt/hda1/boot
   cp -r grub grub.orig
   rm -rf grub
   grub-install --no-floppy --root-directory=/mnt/hda1 --recheck /dev/hda
   

   At this pount the guest OS should boot.

Of course, your mileage may vary, but hopefully there is some useful information here. It was a PITA for me to figure this out so I thought I ought to share it once I did.

JSF-Extensions Design Time brings good news for flow-impaired Java Web application Developers: the JMX PhaseListener.

The implementation of this was really simple. I just took Jean-Francios Arcand's JMXDeploy class, modded it ever so slightly, as you can see in the source code, and called it from a PhaseListener.

I did a screencast about it too.

Hey, why do I need JSF, or any other server side framework for that matter? With Ajax, or things like GWT, can't I just put it all in the client? I mean, let's just do everything in JavaScript!

You're welcome to do that, but if you do, please know that you'll have to do all of these things yourself. As you may guess, JSF already does all of these for you, does them quite well, and does them in a way that is an industry standard, with the brainpower of leading minds from Oracle, Sun, IBM, Apache, the Open Source Community, and others.

This is why I have been spending my spare time trying to get Project jMaki to have first class support for JSF as a core part of its feature set and value proposition. In fact, if you support this idea, please send an email to the jMaki User list saying that you think this is important. For some exmples of this in action, please see here, here, here, and here.