netbooting the jboss petstore
./bin/run.sh --netboot http://jboss.sf.net/demo/netboot --config default
Pretty soon, depending on the speed of your net connection, you're running a minimal JBoss 3.0 server. It's amazingly cool. And on the advanced netboot page, there's this hopeful suggestion:
This configuration provides the required components for Sun's Java Pet Store demo running inside of JBoss!
./bin/run.sh --netboot http://jboss.sf.net/demo/netboot --config petstore
Ah, the Pet Store! Just what I'm looking for. That'd be awesome. Except, oops,
TODO: Make the config... this won't work until there is a config up there...
OK, now I'm curious. A fairly recent jboss-development list message notes that the current JBoss CVS tree includes, under applications, a builder that can migrate Sun's Pet Store to JBoss and even netboot it. I tried it, and the screenshot displays the hopeful result. Unfortunately, it doesn't work. The Pet Store
build deployment gave me a bunch of these messages:
09:16:44,483 WARN [verifier] EJB spec violation:
Bean : LineItemEJB
Warning: The class must provide suitable implementation of the hashCode() method.
Now I'm a complete JBoss novice, so there are a million ways I could have gotten this wrong. Very possibly some reader of this posting will point me to the forehead-slapping solution. But still, you've got to wonder.
"Marketing," wrote Marc Fleury on the list, "ain't it a bitch." Perhaps, but it strikes me that if a working netbootable Pet Store were visible anywhere on the net -- or heck, forget netboot, just a working JBoss 3.2/4.0 Pet Store that could be downloaded and dropped into a deployment directory on a test server -- then those URLs would become rather well known whether or not they were marketed. I think the word we are looking for here is 'finishing':
That extra touch is called finishing work, and it's the kind of thing that, too often, we in open source don't do well. I'm not sure why, but my guess is that in the hierarchy of needs, finishing work provides little positive reinforcement to open source developers. [Zope Dispatches]
Paul Everitt made this same point at the OSCOM conference I recently attended. It's a profound issue for open source.
Former URL: http://weblog.infoworld.com/udell/2003/06/10.html#a718