Browsing articles from "April, 2012"
Apr
18

Eclipse: Insufficient access privileges to apply this update.

By Rob Warner  //  Development, Java  //  3 Comments

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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=344977

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:

/Applications/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/epp.package.jee.profile

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.

Apr
17

Learn to Read the Source, Luke

By Rob Warner  //  Development, Software  //  No Comments

Learn to Read the Source, Luke:

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.

Apr
5

Developer Interview Advice from a Designer

By Rob Warner  //  Development  //  No Comments

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.”

Apr
3

Debugging Through Google is Rotting My Brain

By Rob Warner  //  Development, Java  //  No Comments

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.solr.home and 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 solr.solr.home to /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.

About

I'm Rob Warner, and I'm a software developer. I live in Jacksonville, Florida, and work for Availity, LLC. The postings on this site are my own and do not necessarily reflect the views of Availity.