groovy: how to print the classpath

Found this really helpful blog post that got me printing out the classpath in one of my Groovy classes. I was debugging why my logback.groovy configuration wasn't getting picked up (because, inded it wasn't on the classpath!)

From the logback FAQ:

Where should the configuration files such as logback.groovy, logback-test.xml or logback.xml be located on the classpath?

Configuration files such as logback.groovy, logback-test.xml or logback.xml can be located directly under any folder declared in the class path. For example, if the class path reads "c:/java/jdk15/lib/rt.jar;c:/mylibs/" then the logback.xml file should be located directly under "c:/mylibs/", that is as "c:/mylibs/logback.xml". Placing it under a sub-folder of c:/mylibs/, say, c:/mylibs/other/, will not work.

Here's how to print the classpath, thanks to the original poster:

def printClassPath(classLoader) {
  println "$classLoader"
  classLoader.getURLs().each {url->
     println "- ${url.toString()}"
  }
  if (classLoader.parent) {
     printClassPath(classLoader.parent)
  }
}
printClassPath this.class.classLoader

how to fix groovy console warnings

Was getting these annoying messages repeatedly in groovysh and groovyConsole:

java.util.prefs.BackingStoreException: java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactory

Solution: delete xml-apis and xercesImpl jars from your ~/.groovy/lib directory:

enkomion [15:20:56] ~/.groovy/lib $ rm xml-apis-1.4.01.jar
enkomion [15:20:59] ~/.groovy/lib $ rm xercesImpl-2.10.0.jar

unmet dependencies in aptitude: when all else fails

A routine update of system packages on 12.04 failed with errors of a broken package due to unmet dependencies. I upgraded from 10.04 to 12.04 a month ago, and things have been working relatively well since then, but somehow something broke in postgresql:

dpkg: dependency problems prevent configuration of postgresql-9.1:
 postgresql-client-9.1 (9.1.6-0ubuntu12.04) breaks postgresql-9.1 (<< 9.1.6-0ubuntu12.04) and is installed.
  Version of postgresql-9.1 to be configured is 9.1.5-1~lucid3.
dpkg: error processing postgresql-9.1 (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Errors were encountered while processing:
 postgresql-9.1
E: Sub-process /usr/bin/dpkg returned an error code (1)

So I tried to fix this with all the tools I was aware of, but to no avail, and then finally gave up and decided to postgresql altogether since I didn't need it right now.

enkomion [19:14:55] ~ $ sudo apt-get purge postgresql-common
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 postgresql-9.1 : Depends: postgresql-common (>= 115~) but it is not going to be installed
 postgresql-client-9.1 : Breaks: postgresql-9.1 (< 9.1.6-0ubuntu12.04) but 9.1.5-1~lucid3 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).


enkomion [19:15:07] ~ $ sudo apt-get install -f 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libutouch-evemu1 libutouch-geis1 libutouch-frame1 libutouch-grail1 libtrove-java
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  postgresql-9.1
Suggested packages:
  oidentd ident-server locales-all
The following packages will be upgraded:
  postgresql-9.1
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
1 not fully installed or removed.
Need to get 0 B/4,298 kB of archives.
After this operation, 5,915 kB disk space will be freed.
Do you want to continue [Y/n]? Y
dpkg: dependency problems prevent configuration of postgresql-9.1:
 postgresql-client-9.1 (9.1.6-0ubuntu12.04) breaks postgresql-9.1 (<< 9.1.6-0ubuntu12.04) and is installed.
  Version of postgresql-9.1 to be configured is 9.1.5-1~lucid3.
dpkg: error processing postgresql-9.1 (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Errors were encountered while processing:
 postgresql-9.1
E: Sub-process /usr/bin/dpkg returned an error code (1)

Even the usual "sudo apt-get update" and manually trying to do "sudo apt-get purge postgresql*" didn't work.

dpkg: dependency problems prevent configuration of postgresql-9.1:
 postgresql-client-9.1 (9.1.6-0ubuntu12.04) breaks postgresql-9.1 (<< 9.1.6-0ubuntu12.04) and is installed.
  Version of postgresql-9.1 to be configured is 9.1.5-1~lucid3.
dpkg: error processing postgresql-9.1 (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Errors were encountered while processing:
 postgresql-9.1
E: Sub-process /usr/bin/dpkg returned an error code (1)

I was frustrated with trying to fix this manually, and just wanted to get rid of all postgresql* packages altogether from my system. But even this wasn't happening via aptitude, and was becoming increasingly painful. Finally found the solution at http://dabase.com/e/01169/ which saved the day.

enkomion [19:20:10] ~ $ sudo dpkg --force-depends --purge postgresql*
(Reading database ... 361318 files and directories currently installed.)
Removing postgresql-server-dev-9.0 ...
Removing postgresql-client-9.0 ...
Removing postgresql-client-8.4 ...
Removing postgresql-client ...
Removing postgresql ...
Removing postgresql-common ...
 * No PostgreSQL clusters exist; see "man pg_createcluster"
Removing 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by postgresql-common'
Purging configuration files for postgresql-common ...
dpkg: warning: while removing postgresql-common, directory '/var/lib/postgresql' not empty so not removed.
Removing postgresql-client-9.1 ...
Removing postgresql-client-common ...
Purging configuration files for postgresql-client-common ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...

enkomion [19:34:30] ~ $ sudo apt-get install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libutouch-evemu1 libutouch-geis1 libutouch-frame1 libutouch-grail1 libtrove-java
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

All postgresql* packages finally removed without fuss :)

 So this is the solution for forcefully removing broken packages:

dpkg --force-depends --purge java-gcj-compat-dev
apt-get -f install

java: create maps the easy way with guava

Traditional:

private HashMap indexMap = new HashMap();

indexMap.put("low", 1);
indexMap.put("medium",2);

indexMap.put("high",3);

Better (via Google Guava):

ImmutableMap indexMap = ImmutableMap.builder()
            .put("low", 0) 
            .put("medium", 1) 
            .put("high", 2) 
            .build();

source

nothing like a good ol' flame war to cure the blues

Great article by Martin Fowler:
http://java.dzone.com/articles/martin-fowler-orm-hate

Crisp, cool and informative as usual. 


But then things started to warm up a little in the comments section:

Frederic Bellier replied on Wed, 2012/05/09 - 9:17pm 

Woah!!! The world has come to an end.
Martin Fowler who I usualy consider as an influencial professional is now writting misinformed articles.
Where to start? There are just too many untruth and mis-information in this article - I cannot go over them all.
But for everyone interested in this topic. ORM does not work and will never work. I have 20 years experience in this field and have build some of the largest systems around where performance is paramount. I can tell you ORM cannot possibly work becuase it automatically means the access to the data will be much slower. This is not due to the incompetence of the dev involved but because of the ill conceived architecture of ORM. I have had the top engineers who build the ORM tools from the vendors telling me this.
The idea to conect an object graph in memory and a relational data structure is simply flawed. The network inefficiencies resulting from that approach are astronomical.
Moreover, ORM is based on a false premise - that SQL is hard. In fact SQL is simple. And for everyone out there interested in computer science. LEARN SQL. It is simple fast and cannot be replaced by anything else since it is a SET language to work on Set data. Replacing on standard Set language by a multitude of proprietary languages (one for each vendors) is of course silly.
And by the way - iBatis is not an ORM tool. It is actually a very good tool - this one works. It simply allows you to populate your objects from a result set.
Putting iBatis in the same categories as Hibernate only shows MF ignorance in this topic. I guess it is time to retire.
FB

Some pretty decent and well-informed arguments, but it does smell slightly trollish. Hmmm, maybe I should put some popcorn in the microwave.


And yes, I was right! The fanboys are IRKED!!! :D

Jammer Man replied on Thu, 2012/05/10 - 11:53am  in response to:FredericBell 

In your 20 years of experience you obviously haven't learned very much at all. I'd pick MF's opinion over some garden-variety d0uche troll like yourself any day.

ROFLMAO!!! Haven't laughed this hard in a long time!!! Thank you God for tech flame wars! :D

groovy: logback configuration

Logback configuration is much easier in groovy than in xml:

import ch.qos.logback.classic.encoder.PatternLayoutEncoder
import ch.qos.logback.core.FileAppender
import ch.qos.logback.core.ConsoleAppender
import static ch.qos.logback.classic.Level.DEBUG
import ch.qos.logback.core.status.OnConsoleStatusListener


/*
 * see http://mrhaki.blogspot.in/2010/09/grassroots-groovy-configure-logback.html
 * and http://logback.qos.ch/manual/groovy.html 
 * for logback.groovy examples
 */

appender("FILE", FileAppender) 
{
    def ts = timestamp("yyyy-MM-dd'_'HH-mm-ss")
    
    file = "./logs/trybeTest.${ts}.log"
    append = true
    encoder(PatternLayoutEncoder) 
    {
        pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
    }
}


appender("CONSOLE", ConsoleAppender) 
{
    //append=true
    encoder(PatternLayoutEncoder) 
    {
      pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
    }
}

//logger "scratchpad", DEBUG, ["CONSOLE"]
root DEBUG, ["FILE", "CONSOLE"]

upgrade from 10.04 to 12.04 "not recommended" until july

Was hoping to upgrade my Lucid Lynx laptop to Precise Pangolin today.

Though I was an unflinching Windows user before, I simply fell in love with Ubuntu (and a few other distros like Linux Mint - which happens to be derived from Ubuntu) and started using it in dual boot mode. Eventually, I became less and less dependent on the Windoze drug. Once the withdrawal symptoms (couldn't play my favorite PC games) passed, I realized I didn't need Win at all.

I got rid of my dual-boot and deployed Lucid Lynx and Mint Julia on my work and personal laptops, respectively and there's been no looking back. I only needed Win7 once in the last year, and that was when I had to do some WinPhone7 development+testing at work. (And perhaps a few times more when I gave in to my gaming craving :P)

Lucid has been an awesome, fast, dependable companion, but I heard really good stuff about PP since its recent release and I eagerly wanted to give it a test drive.

However, just when I was about to plug in an external drive for a pre-upgrade backup, I read this on the official upgrade docs:

Upgrading from Ubuntu 10.04 LTS to Ubuntu 12.04 LTS

It is generally recommended that users of Ubuntu 10.04 LTS wait until the first point release, due in July, before upgrading.

Furthermore, seems that there was a major bug in upgrading from LL to PP from CD where one of the Ubuntu developers has this to say:

It's OK for you to try it, but we aren't going to encourage it because
in our experience the extra testing from early-adopter upgraders before
.1 is important in making sure that upgrades are really solid for
everyone by the time we turn it on by default.

Oh well. A couple more months to go before I get PP goodness on my lappy. But I will try a PP live boot from pen drive some time soon.