I use Eclipse for all my Java development (and Mac OS X for all my development). Today, a bug with portlet deployment to Liferay required me to update my Eclipse installation. For awhile, I’d seen (and ignored) an error when I ran Eclipse’s Check For Updates: the Eclipse IDE for Java EE Developers selection was grayed out with the message:
Insufficient access privileges to apply this update.
I assumed that the IT group here at work hadn’t given my user permissions on the
/Applications/eclipse directory, and I’d never been motivated to investigate. Today, that motivation came. I quickly determined the fallacy of my assumption and, with nowhere else really to turn, I ran to Google. I found this:
It had this explanation:
In case anyone wants to workaround it manually, go to:eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\SDKProfile.profile
- Edit the most recent profile file
- Find the section in comment #1
- Remove the line:<property name='org.eclipse.equinox.p2.type.lock' value='1'/>
- Now start Eclipse and update it
I didn’t have that file, but I rooted around that directory and found a 0-byte file called
.lock in this directory:
I don’t know where that file came from, but since it looked suspicious (and I was reasonably confident I could recreate the file with its original contents if it weren’t the culprit), I deleted that file, restarted Eclipse, and now my update works.
No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you’re likely to find. This will be true forever, so the sooner you come to terms with this, the better off you’ll be as a software developer.
(Via Coding Horror)
Jeff Atwood’s take on a post by Brandon Bloom. This is my beef with comments as well–some folks push “well-commented” code, but comments rot disproportionally faster than the code they describe. No one opens bugs on comments. No one writes unit tests for comments.
Help files often lie as well.
I was chatting with one of the designers I work with about his interview experience when he was hired, and he remarked how interesting it was that much of the interview focus was on how his personality and work patterns would fit with the team, and less on his design skills or resume. He asked me what developer interviews here were like, and I said that, back when I did interviews, we made interviewees write code on the white board. He pondered this a few moments, and then said, “Hmm. You should have them write some HTML, too.”
A couple of weeks ago I built a National Provider Identifier (NPI) lookup app as a proof of concept for the Vaadin portlet stuff we’re doing. For the search portion, it used a publicly-available, for-pay REST service to search for a provider’s NPI. Our architect, however, pushed me to the freely downloadable NPI data file and told me to set up an Apache Solr instance to do the search.
I know bupkis about Apache Solr except that it embraces the Flickr spelling approach and it lets you search for things, but an online tutorial and a few Ruby scripts later and I had a working Solr instance on my local machine, complete with the entire NPI database. Spinning up Solr with the NPI database on the target Linux server proved just as easy. When I discussed Solr startup scripts with the architect on the project, however, eerie background music started playing and I knew I was in for trouble. He told me to install the Solr webapp and run it on the app server instead of as a standalone server.
Actually, I had no such foreboding. The request was reasonable and the approach superior, so I found and installed
solr.war on the app server. I also configured the two app server variables that I’d read were necessary (
solr.data.dir). I fired up the app server and tried to access the Solr data and got an error: “missing core name in path.” Hmm. Time to debug. And you know what I did first, don’t you? I Googled “missing core name in path” and got a page of magic answers.
I read through a ton of results, trying all the solutions I found (even those that made no sense), and nothing worked. I became more and more desperate, especially because it was Friday afternoon and I was scheduled to go on vacation all the next week. I eventually became convinced that my app server didn’t see the
solr.solr.home variable I’d configured, so I began spraying variable declarations into my app server, anywhere I could find a place to define a variable, like a dog marking trees. I stopped and started the server as if I were driving in Chicago’s rush hour. Each restart brought hopeful anticipation and glum dejection. I was ready to juke out the architect, write an init script for a standalone Solr instance (which worked fine!), and blame the sysadmins if it were ever detected.
Before acquiescing, however, I decided to look at the log files, which showed me that the app server knew all about my
solr.solr.home variable. I was chasing the wrong squirrels. I continued reading the log file, though, and found this:
[#|2012-03-16T21:09:18.721+0000|SEVERE|glassfish3.0.1|org.apache.solr.core.CoreContainer|_ThreadID=27;_ThreadName=Thread-1;|java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or '/opt/solr/./conf/', cwd=/opt/liferay-portal-6.0.6/glassfish-3.0.1/domains/domain1/config
Aha! A real error message! I checked, and
solrconfig.xml was indeed not in
/opt/solr/./conf — it was in
/opt/solr/npi/solr/./conf. I changed my
/opt/solr/npi/solr, restarted, and my search was on!
At this point, I should be claiming victory. After all, I weaned myself from debug-by-Google-search and returned to old fashioned debugging by looking through log files and figuring out exactly what’s going on. Alas, however, I wasn’t the one who thought to look at the log files. One of the Google results I read suggested I do that.
- April 2017 (1)
- June 2016 (1)
- September 2015 (1)
- April 2015 (1)
- January 2015 (1)
- December 2014 (1)
- November 2014 (2)
- October 2014 (1)
- April 2014 (1)
- March 2014 (2)
- January 2014 (3)
- August 2013 (2)
- July 2013 (2)
- May 2013 (3)
- April 2013 (6)
- February 2013 (1)
- January 2013 (1)
- November 2012 (6)
- September 2012 (1)
- August 2012 (6)
- July 2012 (10)
- June 2012 (4)
- May 2012 (7)
- April 2012 (4)
- March 2012 (8)
- February 2012 (7)
- January 2012 (7)
- December 2011 (1)
- November 2011 (1)
- September 2011 (4)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (4)
- April 2011 (2)
- February 2011 (1)
- January 2011 (1)
- December 2010 (3)
- November 2010 (3)
- October 2010 (4)
- September 2010 (6)
- August 2010 (96)