What's That Noise?! [Ian Kallen's Weblog]
Thursday March 11, 2004
expiring application views A while back I'd closed a UI bug where the end-user was seeing data displays with stale data. I implemented a servlet filter to stuff some cache-defeating headers into all of the page requests. That bug was effectively squashed.
After the next build was released, a new bug was filed that the browser "Back" button didn't work anymore. MSIE would display an error message about the content being expired (indeed, I'd instrumented the filter to send an HTTP Expires: header) whereas Mozilla (my browser) wasn't quite so facist with the shrill error messages.
The resolution was that the Expires header was ditched. Something else came up with screwy caching behavior and one of my colleagues turned off the filter, declaring that using META HTTP-EQUIV tags in the JSP was the "right" way to fix it. I never got a good explanation as to why that was "right" but as long my old bug wasn't reopened, I didn't lose any sleep over it.
I believe they say, "c'est la vie"
Now OnJava has a pretty good discussion of these issues, here it is
( Mar 11 2004, 11:57:27 PM PST )
Permalink
Tuesday March 09, 2004
portals here, portals there I've been working on web-based management consoles for a long time now. Some of these projects I consider enduring successes, others, well, not so much. But over the years, the state-of-the-art for web-based management interfaces has grown more sophisticated -- everything these days, so it seems, is implemented as a portal.
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
Debugging a resume One of the problems with maintaining your resume as you would an application is that you inevitably end up introducing bugs. Having a bug in your resume is probably not a good thing.
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
f*cked! I carpooled into the City on Monday as if it were Just Another Workday but I knew it wasn't. The company shutdown it's operations, all employees were given a short severance and timeoff and turned in our keys, company credit cards, and so forth. So that's it. That's all.
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
- have a resume that expanded/collapsed the various data elements
- use xdoclet to generate struts-config.xml
![[Valid RSS]](/images/valid-rss.png "Validate my RSS feed")