Tuesday March 09, 2004

The content management stuff I used to do at Salon.com has flourished; going from being an ill-conceived spin-off business to a successful open source project (Bricolage) [warning: I like java as much as anyone but I also like Perl, if you're a Perl-phobe, don't click that link!]. The web server management stuff I did at Covalent was also admittedly ill-conceived but in the end it was an interesting exercise in identifying the customer's pain points, pinning down their concrete scenarios and appropriately scoping a product to fulfill those needs. These products had little in the way of end-user customization. The display that the user saw was the display that was coded into the UI logic. As a reference point, that's not necessarily a bad thing. But as one sees the different roles that end-users fulfill using an application, allowance for end-user customization of the display seems increasingly important. Thus, the value of decomposing the display elements into portlets and allowing them to be aggregated by a portal framework.

The next product I worked on at Covalent was an application management web interface. The first version had a nice dashboard oriented entryway portal but had hardly any end-user customization as it displayed system objects. The architecture that was decided upon for the next generation ("two oh") product specified that just about everything be presented as a portal, ostensibly allowing the varyingly-role-filling end-user to see what was important to them at all times.

The framework used for the portal was a homebrew built on struts and tiles, for two oh we had a homebrewed jsr-168'ish framework underway. I'm certainly glad we didn't paint ourselves into a costly, proprietary corner with one of the Big Commericial Portal Frameworks. I'm actually wondering how the traditional big boys in the web infrastructure market can sustain six-figure price tags for frameworks like that when there has been so much activity around jsr-168 and open source portals. ( Mar 09 2004, 08:20:45 AM PST ) Permalink

Monday March 08, 2004

Since the data from my resume is kept in an XML file and I've had requests to have it sent as plain text (instead of just sending the URL, which is what I'd been doing), I decided to turn it into an opportunity to mess with some XSLT. Everything was looking pretty good in my development sandbox (a Tomcat instance on my laptop and Eclipse) so I warred it up and deployed it on the production server.

The link to the plaintext version (which worked fine in my sandbox) was puking on the live server. It was generating a server 500 error, a NullPointerException in java.net.URL - oy vey! So I backed up, looked at the Parts inner class in the URL class... it wasn't readily apparent why it was NPE'ing on me - sonuvabitch!

After some slighly panicked puzzling ("I hope no prospective employer-types are clicking on that link now for the plaintext version"), it hit me: in my development sandbox, the webapp was deployed fully expanded, on the production server, it was deployed as a war file... that totally changes the way the XSLT file is accessed and turned into a stream for the Transformer class. The only reason I'd been accessing it as a URL to begin with was the Transformer's unhappiness with being given a plain-old InputStream from the ServletContext (it was throwing MalformedURLException).

The long and the short of it is: if you're accessing an XSLT stylesheet from inside a webapp, be careful how you access it and how you deploy the webapp -- having a request for your resume produce a server 500 error doesn't look so good. ( Mar 08 2004, 02:29:42 PM PST ) Permalink

Wednesday March 03, 2004

Since then, I decided to scratch an itch I've had. I've used Jakarta Struts for long time but have always found the maintenance of the deployment descriptor ("struts-config.xml") to scale poorly. Since I wanted to

1. have a resume that expanded/collapsed the various data elements
2. use xdoclet to generate struts-config.xml