warning: iPhone/iPod Touch: application executable is missing a required architecture.
At least one of the following architecture(s) must be present: armv6 (-19033)

I think the use of this Xcode setting “$(ARCHS_STANDARD_32_BIT)” has changed its meaning since,..sometime. We solved this by doing this:

• Goto Project->Build Settings
• Find Architectures and change it from $(ARCHS_STANDARD_32_BIT) to two new values armv6 and armv7
• While you are there, you can also check that Build Active Architecture Only has been set to No for the AdHoc and AppStore targets

This code:

NSArray *a1 = [[NSArray alloc] init];
NSArray *a2 = [[NSArray alloc] init];
NSLog(@"a1 == a2 => %d", (a1 == a2));

says:

a1 == a2 => 1

which indicates, that even though it looks like we instantiate 2 objects, the “a1″ and “a2″ variables point to the same object.

It doesn’t matter much how we instantiate the empty NSArray. We could also do:

NSArray *emptyArr = [[NSArray alloc] init];
NSArray *a1 = [NSArray arrayWithArray:emptyArr];
NSArray *a2 = [NSArray arrayWithArray:emptyArr];

// or

NSArray *a1 = [NSArray array];
NSArray *a2 = [NSArray array];

// or

NSArray *a1 = [NSArray arrayWithObjects:nil];
NSArray *a2 = [NSArray arrayWithObjects:nil];

I guess it is because NSArray is immutable, that this optimization was found okay to make. If I add just one object, I can’t reproduce it. So this:

NSArray *a1 = [NSArray arrayWithObject:@"foo"];
NSArray *a2 = [NSArray arrayWithObject:@"foo"];
NSLog(@"a1 == a2 => %d", (a1 == a2));

yields:

a1 == a2 => 0

and maybe more surprising, this code:

NSArray *a1 = [NSArray arrayWithObject:@"foo"];
NSArray *a2 = [NSArray arrayWithArray:a1];
NSLog(@"a1 == a2 => %d", (a1 == a2));

also yields:

a1 == a2 => 0

I would’ve guessed, that “[NSArray arrayWithArray:a1]” simply returned “a1″, because after all, NSArray is immutable. But it seems not to, when the given array isn’t an empty array.

Anyways, I got bitten because I had some code in a setter method with an optimization that went something like this:

if (_ivarArray != newArray) {
   // work the magic
}

and I really wanted to “work the magic”, even though “_ivarArray” previously also was an empty array.

$ vi your-dos-newline-file.txt
:set fileformat=unix
:wq

and you are done. And I am pretty sure this can be one-lined too, with the proper v(h)im-sical command tooling

xcodebuild -configuration Release -target my -sdk iphonesimulator4.0 clean build
xcodebuild -configuration Release -target my -sdk iphoneos4.3 clean build
lipo -create -output build/libmy.a build/Release-iphonesimulator/libmy.a build/Release-iphoneos/libmy.a

The final fat library created by “lipo” can now be used to link both Simulator and iOS builds.

When you construct the above lines for your project, a couple of xcodebuild commands that list info about a given xcode project, might come in handy:

xcodebuild -list yourProjectName
xcodebuild -showsdks

Where “-list” list information like “targets” and “build configurations” about given project and “-showsdks” shows the possible sdk names to use.

A dump of the stacks of all threads when the system locked up, told us the culprit was a specific web-service call, and all the stacks were dead in a call to hibernates MultipleHiLoPerTableGenerator.generate method. Like this:

38018:http-7555-140, state=BLOCKED
	org.hibernate.id.MultipleHiLoPerTableGenerator.generate(MultipleHiLoPerTableGenerator.java:204)
	org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:122)
	org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:69)
	org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:179)
	org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:135)
	org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
	org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:800)
	org.hibernate.impl.SessionImpl.persist(SessionImpl.java:774)
	org.hibernate.impl.SessionImpl.persist(SessionImpl.java:778)
	org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:668)
	sun.reflect.GeneratedMethodAccessor553.invoke(Unknown Source)
	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	java.lang.reflect.Method.invoke(Method.java:597)
	org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:365)
	$Proxy62.persist(Unknown Source)
	sun.reflect.GeneratedMethodAccessor553.invoke(Unknown Source)
	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	java.lang.reflect.Method.invoke(Method.java:597)
	org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:240)
	$Proxy62.persist(Unknown Source)
	org.springframework.orm.jpa.JpaTemplate$5.doInJpa(JpaTemplate.java:264)
	org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:183)
	org.springframework.orm.jpa.JpaTemplate.persist(JpaTemplate.java:262)

What’s interesting of this particular web-service call is, that it generates a lot of new rows of a specific JPA mapped entity in the system. Hence, it calls the id-generator a lot of times. And when the system is under heavy load, this particular web-service method is called often, which generates lots of parallel transactions, all trying to generate a lot of ids.

The class was mapped like this:

@Entity
public class DetailRow implements Serializable {

  private Long id;

  @Id
  @Column(unique = true, nullable = false)
  @GeneratedValue(strategy = GenerationType.TABLE, generator = "DetailRow.id")
  @TableGenerator(name = "DetailRow.id", table = "IdSequence", pkColumnName = "Name", valueColumnName = "WaterMark", pkColumnValue = "DetailRow", allocationSize = 1)
  public Long getId() {
    return id;
  }

  public void setId(Long id) {
    this.id = id;
  }
}

Now, it turns out others have had this problem too. The problem is with the MultipleHiLoPerTableGenerator of hibernate, which allocates new ids in a separate transaction (which it must, so that’s kinda okay). But, because it grabs an extra connection while holding an existing connection, it can deadlock when other calls do the same at the same time. The calls can end up hold the one connection all the others need. This is no news, and people have filed bugs (HB-1246 and HHH-1739) in the hibernate bug-db for it. None of them with a fix though.

I myself have no final fix for it. But I have an easy solution, which, at least for us, made the probability for the deadlock so small, that it stopped happening.

Solution

The use of @TableGenerator with hibernate as ORM provider, maps underneath to MultipleHiLoPerTableGenerator. I think we got that covered by now But, there is an interesting parameter “allocationSize” to @TableGenerator. This makes the generator work in “chunks of ids”. Given the “IdSequence” table have a watermark of “123″, and we have set allocationSize to “1000″, the generator will increment watermark to “124″ ONCE and then for the next 1000 ids allocate 123000, 123001, 123002, ..123999 and first THEN, will it touch the “IdSequence” table again, to increment the watermark.

Setting “allocationSize” on @TableGenerator severely lowers the number of times an extra connection is needed, hence also making it a lot less probable, that it will end up in a deadlock. The “bug” is still there, because, technically, it still can happen. But practically, it won’t happen, if setting “allocationSize” high enough.

Caveat

Not many.

Remember that “allocationSize” is multiplied onto the “watermark” value, so to avoid a large unused hole of ids when deploying a new version with a larger “allocationSize”, you should divide the watermark with “allocationSize”.

Also, there can (will) be holes in the sequence, as unused ids from a “chunk” are lost when process dies. No big deal for us. Might be for some.

And what is a “high enough” value for “allocationSize” then? Well, it depends on your system. How many rows are created, and at which rate, and with how many concurrent transactions, related to your connection pool size. Do the math for loaded scenarios and try setting it to what you think is “high enough”.

I started out simple, with these ruby require lines in the top of my ruby sinatra app:

require 'sinatra'
require 'json'
require 'mongo'
require 'mongo_mapper'

Unfortunately, that made vmc update of my app fail. Cloudfoundry couldn’t start the app, and there were no logs or crashlogs to be seen A little trial-n-error told me that it was the require of ‘mongo_mapper’, that made it fail. After some more trial-n-errors and a lot of googling, I could put together the needed bits.

This page at the cloudfoundry site has good info on what is required (and what they know won’t work) when running ruby apps on cloudfoundry. It also said, that I should be using Bundler and a Gemfile to describe my gem dependencies and package the app before deployment. So, I ended up with this Gemfile:

source "http://rubygems.org"
gem 'sinatra'
gem 'json'
gem 'mongo'
gem 'mongo_mapper'

and changed the require-lines in the sinatra application ruby file with this single line:

Bundler.require

When using bundler we then need to do these two steps before vmc push or update (each time dependencies have changed):

bundle package
bundle install

If you don’t have bundler, you can simply do:

sudo gem install bundler

You use them by subclassing them and calling the getBean method when a dependency is needed, like this:

// ..blah blah..inside subclass
MyService myService = getBean("myService");

Okay, here they come..

SpringHttpServlet

package net.techper.server.web;

import org.springframework.context.ApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

public abstract class SpringHttpServlet extends HttpServlet {

  private ApplicationContext context;

  @Override
  public void init(ServletConfig config) throws ServletException {
    super.init(config);
    context = WebApplicationContextUtils.getRequiredWebApplicationContext(config.getServletContext());
  }

  @Override
  public void destroy() {
    context = null;
    super.destroy();
  }

  protected <T> T getBean(String beanName) {
    return (T) context.getBean(beanName);
  }
}

SpringContextListener

package net.techper.server.web;

import org.springframework.context.ApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public abstract class SpringContextListener implements ServletContextListener {

  private ApplicationContext context;

  @Override
  public void contextInitialized(ServletContextEvent sce) {
    context = WebApplicationContextUtils.getRequiredWebApplicationContext(sce.getServletContext());
  }

  @Override
  public void contextDestroyed(ServletContextEvent sce) {
    context = null;
  }

  protected <T> T getBean(String beanName) {
    return (T) context.getBean(beanName);
  }
}

SpringFilter

package net.techper.server.web;

import org.springframework.context.ApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

import javax.servlet.Filter;
import javax.servlet.FilterConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;

public abstract class SpringFilter implements Filter {

  private ApplicationContext context;

  @Override
  public void init(FilterConfig filterConfig) throws ServletException {
    context = WebApplicationContextUtils.getRequiredWebApplicationContext(filterConfig.getServletContext());
  }

  @Override
  public void destroy() {
    context = null;
  }

  protected <T> T getBean(String beanName) {
    return (T) context.getBean(beanName);
  }
}

But…

I started using grails command objects (a bit like Struts form beans) to have the submitted form data data-bound and validated to an object different from the model. Like this:

class UploadDataSetController {
  def uploadDataSetFile = { UploadDataSetFileCommand cmd ->
    if (cmd.hasErrors()) {
      // foo
    } else {
      // bar
      session["UploadDataSetController.UploadDataSetFileCommand"] = cmd
    }
  }
}

class UploadDataSetFileCommand {
   // blah blah
}

As you can see above, I defined the command class inside the file of the controller, which is what the documentation recommends.

But, have a look at what I do in the else block. I put the command instance into session storage. And what is the problem with that? Well, when I change something (no matter what) in the controller file, Grails will recompile it on the fly (which is what I like). But, recompiling will make the class file of the command class different from the class of the instance in the session, giving me ClassCastException when reloading in the browser

I tried moving the command class definition into its own file, which works fine. Only thing is, these won’t be recompiled at runtime, so I need to take the server down and up all the time, when I develop on the command class to get the changes. Not nice.

Actually, I tried something different. I tried keeping the command class definition in the file of the controller, but also providing it with a serialVersionUID definition. But it still failed on me. I think the reason for this being the classloader changing on recompile/refresh.

What I ended up with was the command class definition in the controller when developing heavily on it, and moving it into a separate file after it stabilized, which opened up for changes to the controller without problems.

Any good ideas for better solutions on this?

Now, actually I did know this could be a problem, because unix-like filesystems have had this scaling problem with very large directories for some time now. But I thought I was in the clear, as I was only doing a simple “ls”, which should be able to read all the filenames directly from the directory file. (As opposed to an “ls -l” which actually needs to stat() each inode to get to the extra information needed to present the long listing.)

Another thing that I thought could help me was the fact, that it was a gpfs filesystem, which should have support for very large directories.

The “solution” turned out to be simple. It all dawned on me when I was trying to kill the “ls” command that was hanging. I did a “ps” + “grep” after it, and got this command listing from “ps” output:

/bin/ls -N --color=tty -T 0 /my/large/dir

Ahh, an “alias”. On my system, “ls” was an alias to "/bin/ls $LS_OPTIONS", and LS_OPTIONS was set to -N --color=tty -T 0. I am not sure, but I suspect it being the "--color=tty" option, because to color files according to their types and attributes must incur a stat() on each inode.

And gpfs actually does seem to scale well with very large directories. I mean, maybe it is okay that it takes for ages to stat() 700.000+ inodes, but each single stat() call is pretty quick, if you know the exact filename in advance.

Part of a web application we’ve build is dispatching some calculation functionality to a windows based cmdline program. Because we are hosting the application on linux, we are using wine for execution of the calculation program. Suddenly one day, after applying a bunch of bugfix patches, wine became painfully slow to startup. We are talking 25 seconds or so, for what used to take around 1-2 seconds.

After a lot of digging and searching, we found that wine was using a lot of resources on reading fonts. Okay, but why? No new fonts had been installed. After some further digging, in turned out that rebuilding the fontconfig cache, made wine slow. Hugh! A cache of fonts should make it faster.

Yes, using a font cache will make font resolve much faster – if the cache is in a format, that the program using fontconfig understand. It turned out, that the SLES 10 we are running, is using a dead-old 2.3.x version of fontconfig. And this old version of fontconfig only has one set of cache files in “/var/cache/fontconfig“. But, fontconfig builds the cache differently for 32bit and 64bit architectures. Building with 64bit version of fc-cache overwrites the 32bit cache files and vice versa. Our SLES installation and machine architecture is 64bit, but wine is a 32bit program.

Short term solution: Simply build the fontcache with fc-cache32. Luckily, it seems we do not have other important software running on that server, that depends on the 64bit cache.

Long term solution: Upgrade the fontconfig libraries to a not so dead-old version. Newer versions of fontconfig have different cache files for 32bit and 64bit on the same installation.

This post comes from a need I had to start cassandra in multiple instances on a single Mac (testing a cluster configuration out), and failing to do so. Previously on Linux, I had configured multiple instances to bind to 127.0.0.1 and 127.0.0.2 and it worked without any trouble. On the Mac though, I got the exception:

java.net.BindException: Can't assign requested address
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
	at org.apache.cassandra.net.MessagingService.listen(MessagingService.java:138)
	at org.apache.cassandra.service.StorageService.initServer(StorageService.java:319)
	at org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:99)
	at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:177)

Until Jonathan Ellis and Peter Schuller on the cassandra list told me I could alias the extra addresses to loopback using this:

sudo ifconfig lo0 add 127.0.0.2

After that, ifconfig shows the added IP under the “lo0″ device and cassandra can connect to it.

Well, here’s a quick and dirty solution to creating a non-blocking waitFor() call:

  public boolean nonBlockingWaitFor(Process proc, long procMaxTimeoutMillis) throws InterruptedException {
    final long TIMESTAMP_BEFORE_EXECUTE = System.currentTimeMillis();
    boolean hasExited = false;
    while (!hasExited) {
      try {
        // set/calculate your own granularity of check, which fits your procMaxTimeoutMillis
        Thread.sleep(500);
        // using the IllegalThreadStateException side-effect of exitValue() if process hasn't exited
        proc.exitValue();
        hasExited = true;
      } catch (IllegalThreadStateException e) {
        if (System.currentTimeMillis() > (TIMESTAMP_BEFORE_EXECUTE + procMaxTimeoutMillis)) {
          break;
        }
      }
    }
    return hasExited;
  }

This little block of code makes use of the fact, that Process.exitValue() will throw IllegalThreadStateException if one tries to peek at the exit value before the process has exited.

Is it nice? No!
Does it work? Yes!

I have a base class like this:

import org.springframework.test.jpa.AbstractJpaTests;

public abstract class AbstractCxfWsBeanTest extends AbstractJpaTests {
  public static final String[] SERVICE_CONFIG_LOCATION = new String[]{
      "classpath*:/applicationContext.xml",
      "classpath:/datasourceContext.xml",
      "classpath:/cxf.xml",
  };

  @Override
  protected String[] getConfigLocations() {
    return SERVICE_CONFIG_LOCATION;
  }
}

One thing here: cxf.xml is loaded from classpath by the test code, but it resides in src/main/webapp/WEB-INF in my source tree, which is not exactly classpath stuff. I came around that with this little snippet in the <build> section of the maven pom.xml:

  <build>
    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
        <includes>
          <include>*</include>
        </includes>
      </testResource>
      <testResource>
        <directory>src/main/webapp/WEB-INF</directory>
        <includes>
          <include>cxf.xml</include> <!-- needed to make tests have cxf beans injected on them -->
        </includes>
      </testResource>
    </testResources>
  </build>

And finally, I can write a test like this one:

import org.springframework.beans.factory.annotation.Autowired;

public class TestMyWebService extends AbstractCxfWsBeanTest {

  @Autowired
  private MyWebService myWebService; // this is where I get my CXF WS impl injected

  public void testFoo() {
    assertEquals("bar", myWebService.foo());
  }
}

After some investigation we concluded, that, …the database was too loaded. Duh! Okay, so why? It turns out we hadn’t been using the insides of our heads that much. Each webapp deployed on tomcat had its own database pool defined in its own context. With many webapps, this summed up to a large max-value for how many connections we could open against oracle. Something that oracle couldn’t scale to.

So, to maximize throughput and sacrificing a bit on individual request processing time, we decided to define one single pool in tomcat, and let each webapp reference that pool. Here’s how it’s done:

In conf/server.xml in the <GlobalNamingResources> element, define the global database pool with a <Resource> element like we normally do inside each context. Something like this:

  <GlobalNamingResources>
     <Resource name="jdbc/yourglobaldsname" auth="Container" type="javax.sql.DataSource"
               maxActive="20" maxIdle="5" maxWait="20000"
               username="scott" password="tiger" driverClassName="oracle.jdbc.OracleDriver"
               url="jdbc:oracle:thin:@dbhostname:1521:sidname" initialSize="0" minIdle="1"
               validationQuery="select count(*) from smalltable"
               testOnReturn="false" testOnBorrow="true" timeBetweenEvictionRunsMillis="60000"
               numTestsPerEvictionRun="20" minEvictableIdleTimeMillis="120000"/>
  </GlobalNamingResources>

Then, in each context you remove the resource definition of the per context pool, and instead inserts a <ResourceLink> element, to refence the global pool. Like this in conf/Catalina/localhost/yourcontext.xml:

    <ResourceLink name="jdbc/yourdsname" global="jdbc/yourglobalds" type="javax.sql.DataSource" />

With a lot less load on the database, all users get a chance to get their work done. So by actually lowering the amount of concurrent requests we allow against the database, we get both better throughput and better processing time pr. request.

Just wanted to give a quick view on what IDEA can do for you with some of the latest JetGroovy support for @Grab annotations. With my projects I use maven for building, and as such, I have my dependencies in the pom. I then use the excellent maven integration in IDEA by simply opening project from the pom.xml, hereby letting IDEA build dependencies for all modules. Works well.

With my groovy code module though, I have the dependencies listed as @Grab annotations instead, as that will help my deployment. What I do not want then, is to have to put them into the pom.xml too. In essence, IDEA should be able to add module dependencies by recoqnizing the @Grab annotations.

Luckily, this is under way, and you can already now try it out. There is a small extra Grab plugin, that needs to be installed. When you have that plugin installed, you get an intention action for the @Grab annotations, saying if you would like to download. If executed, they will also appear on the module dependencies, nicely marked with “Grab: ..” names.

For further info see this issue and the Grab plugin can be found here.

One small note: If running maven-based projects in IDEA like me, you might need this Ivy dependency

    <dependency>
        <groupId>org.apache.ivy</groupId>
        <artifactId>ivy</artifactId>
        <version>2.1.0</version>
    </dependency>

…in your pom to make the plugin work. I think a fix is under way for this though

@Grapes([
   @Grab(group = 'oracle', module = 'ojdbc15', version = '11.2.0.1.0'),
])
class SqlTool {
  private sql;

  public SqlTool(url, driver, username, password) {
    this.sql = Sql.newInstance(url, username, password, driver)
    // ... do sql stuff
  }
}

new SqlTool("jdbc:oracle:thin:@dbhost:1521:dbsid", "scott", "tiger", "oracle.jdbc.driver.OracleDriver")

Because the oracle driver will be in the GroovyClassLoader, which is down the hierarchy relative to java.lang.Class, which is up in the root classloader, the loading will fail.

The @Grab annotation seems not to support the definition of which classloader to add the dependencies to, but luckily we have programmatic access to grape too. What we need to do is something like this:

import groovy.sql.Sql

def classLoader = this.getClass().getClassLoader();
while (!classLoader.getClass().getName().equals("org.codehaus.groovy.tools.RootLoader")) {
  classLoader = classLoader.getParent()
}

// force grape to use the root classloader - to ensure that Class.forName works for dependencies
groovy.grape.Grape.grab(group:'oracle', module:'ojdbc15', version:'[11.2.0.1.0,)', classLoader: classLoader)

class SqlTool {
  private sql;

  public SqlTool(url, driver, username, password) {
    this.sql = Sql.newInstance(url, username, password, driver)
    // ... do sql stuff
  }
}

new SqlTool("jdbc:oracle:thin:@dbhost:1521:dbsid", "oracle.jdbc.driver.OracleDriver", "scott", "tiger")

Use Grape!

With groovy comes Grape and the @Grab anotation. Grape is capable of downloading dependencies from maven repositories, much like maven does at compile time, but Grape can do it at execution time of the groovy script. In addition to the automatic resolving and downloading of dependencies, Grape is also capable of adding the dependencies on the script classpath before running it. Cool eh!? Here’s a small example:

package net.techper.foo.bar;

import org.jfree.chart.JFreeChart
import org.joda.time.DateMidnight

@Grapes([
   @Grab(group = 'jfree', module = 'jfreechart', version = '1.0.12'),
   @Grab(group = 'joda-time', module = 'joda-time', version = '1.6'),
])
class YourCoolTool {
   ....
}

This script use jfreechart and jodatime, both of which will be downloaded at runtime and added to classpath before the actual script execution.

Grape Internal and Config

Of course, dependencies only need to be downloaded the first time. The downloaded files are kept in $HOME/.groovy/grapes in a maven-like repository structure.

So what about dependencies that are not in the public repository? Well, you can get them too, as long as the target environment, in which the groovy script is executed, can reach the local repository, where you have these non-public dependencies stored.

Internally, Grape is implemented with Ivy. And Grape can be configured with a Ivy configuration file. Inside the jar distribution of standard groovy lies a default Ivy config, which has some of the major maven repositories predefined. You can provide your own though, by adding a file $HOME/.groovy/grapeConfig.xml which could look something like this:

<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
  <resolvers>
    <chain name="downloadGrapes">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
      </filesystem>
      <!-- todo add 'endorsed groovy extensions' resolver here -->
      <ibiblio name="codehaus" root="http://repository.codehaus.org/" m2compatible="true"/>
      <ibiblio name="ibiblio" m2compatible="true"/>
      <ibiblio name="java.net2" root="http://download.java.net/maven/2/" m2compatible="true"/>
      <ibiblio name="yourid" root="http://your/local/maven/repository/" m2compatible="true"/>
    </chain>
  </resolvers>
</ivysettings>

Notice the extra ibiblio element, that is used to define a private repository!

All this makes it possible to write a small script in groovy, deploy it simply by copying it to the target environment, and then execute it at that place with no extra fuss.

If you are using selenium rc to remote control a Safari on a Mac, remember to turn off pop-up blocking, or else your tests will hang in “selenium.start()” somewhere deep down in HttpURLConnection.getResponseCode() because the selenium-rc server never returns with any content.

In Safari menu, de-select “Block Pop-Up Windows”.

Let’s just say this wasted some time on me, so hope this will help someone out there in the same starter problems

If you have Hibernate configured to use JDBC batching, then statements in the same transaction might be batched into one or few update trips to the server. In case of any errors when performing the batch operation, you wont be able to see which statement that failed. What you will see is something in the lines of this stacktrace:

org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:266)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
	...
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (XXX) violated
	at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10055)
	at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:213)
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
	... 112 more

You can see the offending SQL exception, in this case a Oracle unique constraint violation, but you cannot see the SQL from the batch.

Hibernate uses a class called org.hibernate.util.JDBCExceptionReporter when logging JDBC exceptions. It either WARN of ERROR logs, and most people have at least ERROR level activated for something like hibernate. But, this little piece of the class is interesting:

	public static void logExceptions(SQLException ex, String message) {
		if ( log.isErrorEnabled() ) {
			if ( log.isDebugEnabled() ) {
				message = StringHelper.isNotEmpty(message) ? message : DEFAULT_EXCEPTION_MSG;
				log.debug( message, ex );
			}
			while (ex != null) {
				StringBuffer buf = new StringBuffer(30)
						.append( "SQL Error: " )
				        .append( ex.getErrorCode() )
				        .append( ", SQLState: " )
				        .append( ex.getSQLState() );
				log.warn( buf.toString() );
				log.error( ex.getMessage() );
				ex = ex.getNextException();
			}
		}
	}

What is does is WARN and ERROR log a given exception and its causes. But it as has a part only executed, if DEBUG level has been turned on for this particular class/logger. It DEBUG logs the incoming parameter message and this message just so happens to be the offending SQL statement.

So, turn on DEBUG level for the org.hibernate.util.JDBCExceptionReporter logger and get more information on your failing SQL.

Okay, I know that was a bit harsh, and I do use basic auth myself sometimes. Like for instance with something dead-simple on an intranet, where we just need to shut out the masses a bit.

But what is wrong with basic auth then?

Logout Not Possible

Because the browser remember the authentication data and keep resending it for each request to the host authenticated against, there can be no logout, aside from closing the browser. Often, this is seen done with Javascript (closing the browser window), but a) it is not safe as the client can say no and b) some browsers deny it.

It Does Not Present Itself Nicely to the Client

It is the browser, that pops up a dialog. Basically, you cannot as a developer, control how this dialog looks and behaves. And it looks different in each browser. So, you cannot even determine if it needs to ask for “username”, “login” or …

Also, the application cannot show meaningful information to the client, when authentication goes wrong. This could be “you have xx tries left, before the login is locked”.

No Way To Provide Extra Functionality

Like a “change password” option, when the login has expired. Or a “remember me” option. Or whatever the application would like. Again, it is the browser, that does it all.

All this stems from the fact that it is the browser, that controls the authentication. It is the browser, that stores the authentication data and send it on with each request. And it does not have an API or the like to clear it, hook into missing auth or anything like it. The application is out of the loop.

Just say no!