I just typed up a huge long post about Julie and I's car-shopping experience yesterday, and just as I was about to hit submit, Phoenix crashed! Friggen browser. It crashes a fair amount too, just never when I had a page worth of data ready to go. I did get a screen shot of about half of it though, so I'll attempt to reproduce it tomorrow. Sucks though - Mozilla and IE never crash, maybe it's time to go back.
I got some advice from Max Anderson (via hibernate-devel mailing list) for implementing the following methods in a BaseObject class for my hibernate objects (or any objects FTM):
public boolean equals(Object o) {
return EqualsBuilder.reflectionEquals(this, o);
}
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
public int hashCode(Object o) {
return HashCodeBuilder.reflectionHashCode(this);
}
Boy, that sure makes things easier, huh? Especially when you compare the toString()
method to my old one:
public String toString() {
StringBuffer results = new StringBuffer();
Class clazz = getClass();
results.append(getClass().getName() + "\n");
Field[] fields = clazz.getDeclaredFields();
try {
AccessibleObject.setAccessible(fields, true);
for (int i = 0; i < fields.length; i++) {
results.append("\t" + fields[i].getName() + "=" +
fields[i].get(this) + "\n");
}
} catch (Exception e) {
// ignored!
}
return results.toString();
}
They both use reflection, but my old one might catch security excaptions. The Javadocs for HashCodeBuilder warn us about this problem:
Alternatively, there is a method that uses reflection to determine the fields to test. Because these fields are usually private, the method, reflectionHashCode, uses Field.setAccessible to change the visibility of the fields. This will fail under a security manager, unless the appropriate permissions are set. It is also slower than testing explicitly.
I'll be using these on Tomcat and I'll let you know if I run into any problems.
I can't seem to get the border-collapse property to work on my tables. Basically, I should be able to specify a border and border-collapse: collapse on a table and this border will be applied to all cells. But I can't get it to work - any ideas? Here's an example:
<table width="300"
style="border: 1px solid black; border-collapse: collapse">
<tr>
<th> </th>
</tr>
<tr>
<td>this cell should have a top border<td>
</tr>
</table>
And here's that same table without the HTML escaped:
|
this cell should have a top border |
A week ago, I reported that Ant's <jspc> task doesn't work with Tomcat 4.1.18. I posted a message to the ant-user mailing list (which is very low traffic BTW, a nice feature in my book) describing my issue. Last night, I received a reply from Steve Loughran, co-author of Java Development with Ant (BTW Steve - great book, you've already got my respect!) The short story is that there is something wrong with the Ant task and someone needs to "sit down and spend an evening looking at [Tomcat's] jasper." The real hope is that a Tomcat Developer could take over maintaining the <jspc> task, and then these types of issues wouldn't occur.
XDoclet 1.2 beta 2 is out! You can download it from SourceForge. Just to clarify, I've been calling the 1.2 beta 1 release beta 2 - guess I screwed up there. Unfortunately, the beta 2 contains neither of the bugs I want fixed. The first bug is something I need fixed to upgrade Roller to use the latest XDoclet, and the second is to generate ActionForms from POJOs. Now that I've been hacking some XDoclet code, I might be able to submit a patch for the first bug, I'll check it out if I get so inclined. Too much to do right now, and that's not a priority.
It turns out that I didn't need to add the setCurrentPlugInConfigObject
method to struts-menu's MenuPlugIn.java
. I just needed to compile struts-menu with the latest struts.jar. This told me that the init(ActionServlet, ApplicationConfig)
had been removed and I had to implement init(ActionServlet, ModuleConfig)
. The ApplicationConfig interface has been deprecated in recent weeks in favor of ModuleConfig, but you would think that this method would be deprecated as well, not removed! Oh well, I've fixed my local version of Struts Menu, but don't know how to handle making a Struts 1.1-compliant version, and a Struts 1.0.x-compliant version. Any ideas are appreciated. You can track this issue in Struts' Bugzilla.