My Linux box was hosting Subversion with no problem. I added a new repository to the several that were already present, and when I checked it out, it said, “301 Moved Permanently”. Excuse me?

As it turns out, there is a 301 error section in the Subversion FAQs. It says that this typically means your Apache configuration is invalid (nope, the rest of my repositories worked just fine) or your repository has the same path as a literal directory on your web root. Ahhh!

Sure enough, my subversion path was http://myserver.com/xyz/, and I had a literal directory named “xyz” in the web root. I changed that directory name, and Subversion would then allow me to checkout the repository with no problem.

In light of the departure of the ColdFusion Weekly podcast (so long Matt and Peter, and thank you!), I have assembled a list of my favorite “shows” or “episodes”. Really, all of the episodes were good and worth hearing. But these episodes were fantastic.

Presented in chronological order:

• v1.5 - IDEs of…April: Came at a perfect time for me, because I had just switched to CFEclipse recently. So it was great confirmation for me and I enjoyed the Eclipse plugin recommendations. This episode is good for anyone still using Dreamweaver or HomeSite.
• v1.6 - Version Control: Also had great timing, because I had already committed myself to exclusively using Subversion but hadn’t yet set up my Subversion server. While you’re at it, check out the follow-up episode on v1.29 - Source Control Revisited. These episodes are a nice way to be introduced to version control for web development.
• v1.10 - Design Pattern Safari: Probably one of the most classic episodes and a must-hear. All about design patterns like beans, DAOs, etc.
• v2.01 - Rise of the Virtual Machines: Discussion of virtualization technology on both Macs and Windows. Great discussion, because I think this is an important technology for web developers; I am a big proponent of virtualization.
• v2.02 - Cryptology and Security: This was very interesting because of the information that was discussed regarding encryption, hashing, and salt.
• v2.15 - Mark Mandel on Transfer: Very good consideration of the popular ORM, Transfer.
• v2.27 - Selenium: Discussion on testing your apps on the client side with Selenium.
• v3.06 - Open Source BlueDragon: Discussion with Vince Bonfanti about BlueDragon going open source.

I will miss Matt’s Vista rants. :-)  Thanks to both of you for all of your hard work.

If you’re hankering for a podcast to listen to, Brian Meloche is picking up where Matt and Peter left off with a new podcast called CFConversations. W00T!

I have a report that is generated by ColdFusion that assists our department with account maintenance on our AD network. It looks for a certain set of accounts, then looks up the account of the employee who “requested” or “authorized” the creation of each account to ultimately get verification from that employee that this network account is still needed. If you don’t respond and indicate you still need the support account, it is tagged for removal when we do our system account cleaning.

The system ran perfectly in the past several years, but yesterday it started dying on one of the LDAP calls with the error: “java.lang.OutOfMemoryError: unable to create new native thread”.

The kicker is that the error only occurs on the production server, even though my development box is hitting the same server and running the exact same JVM and is on the same version of ColdFusion 8. And it isn’t failing on the first LDAP call.

Running short on time, I finally discovered a clunky solution: I would call <cfthread action=”sleep” duration=”750″ /> to give the system a “break” before it made the LDAP call that would always fail. Oddly, this worked. Setting it to 100ms still caused it to crash (although it took longer), so I just went long at 750ms.

My only explanation as to why this works is that Java and/or ColdFusion may not be disposing of the LDAP calls quickly enough to avoid having them pile up and eventually cause an overflow and run out of memory.

I am open to someone describing a more appropriate way to handle this. But in the meantime, this is just a scheduled task that can stand to run a little more slowly. I just hate solutions that feel clunky like this, though.

I was improving the CSS of an old intranet web app (written in early 2001) to be closer to standards-compliance (getting it to just look good in Firefox and Safari would be good enough for me). While I was working on that, I noticed a whole bunch of my CSS that was being completely ignored. As it turns out, all of the code in a separate CSS file that was being imported with @import was not being rendered.

FireBug showed me that the CSS wasn’t being applied to the elements that it should have been applied to. Hmm. Then I used the “Net” tab of FireBug to see that Firefox wasn’t even attempting to load the external CSS file.

The solution is simple. My @import directive was surrounded by other CSS instructions. Whereas IE tolerates this, the actual W3C spec declares that @import directives should appear before any other CSS instructions, and Firefox honors this restriction.

Thus, my @import directive was being ignored. I moved it to the top of the file and everything started working.

The lessons? Don’t abuse @import directives. Ideally, they should be used only to have a single CSS file that imports several smaller functional CSS files as a means to provide some organization to the CSS. I was using @import mixed in with my other CSS instructions, which is not ideal.