/**
 * Applies and toggles a default value
 * to input fields.
 */
jQuery.fn.defaultValue = function(defaultValue, defaultValueColor) {
	return this.each(
		function(e, k) {
			var $t = $(k);
		  	$t.defaultValue = defaultValue;
		  	$t.modified = false;
		  	$t.originalColor = $t.css("color");
		  	$t.defaultValueColor = defaultValueColor == null? $t.originalColor : defaultValueColor;
		  	$t.provideDefaultIfEmpty = function() {
			  	if ($t.val() == "") {
				  	$t.css({color: $t.defaultValueColor});
			  		$t.val(defaultValue);
			  	}
		  	};
		  	$t.clearIfDefault = function() {
			  	if (!$t.modified && $t.val() == $t.defaultValue) {
			  		$t.val("");
			  	}
		  	}

		  	$t.change(function() {
		  		if($t.val() != $t.defaultValue && $t.val() != "") {
		  			$t.css({color: $t.originalColor});
			  		$t.modified = true;
		  		}
		  	});

		  	$t.focus(function() {
		  		$t.css({color: $t.originalColor});
		  		$t.clearIfDefault();
		  	});

		  	$t.blur(function() {
		  		$t.provideDefaultIfEmpty();
		  	});

		  	$t.parents("form").submit(function() {
		  		$t.clearIfDefault();
		  	});

		  	$t.provideDefaultIfEmpty();
		  	return this;
		}
	);
};

And use it like so:

<input id="myField" />
...
$("#myField").defaultValue("Search for...", "gray");

That is, it used to be called that and is still avaiable in Ubuntu under this name (sudo apt-get install qtpfsgui). However, qtpfsgui is discontinued since mid 2009 and has been replaced by the Luminance HDR project.

Since qtpfsgui crashed under ubuntu 9.10 when attempting to save any HDR image, I downloaded the latest luminance version, compiled and installed it like so:

1. Download the luminance source and unpack the folder.
2. Install the dependencies required to compile luminance:
   sudo apt-get install qt4-qmake libexiv2-dev libopenexr-dev fftw3-dev libtiff4-dev libqt4-dev g++ libgsl0-dev
3. Compile luminance (takes a few minues) and install it. Change to the unpacked luminance folder and do:
   qmake
make
sudo make install

That´s it! you now have luminance installed and it should be in your main menu under applications>graphics.
It works perfectly under Karmic.
One of the best things about luminance is that you can play a lot with the algorithms and parameters used to tonemap the HDR into a LDR image. In contrast to many other (commercial) tools, you actually get to know which algorithms are used, who created them and can read a little more on how they work (if you are not to opposed to mathematics) by googling up the corresponding papers on scholar or so. This way, experienced users are able to “squeeze” a lot more out of their HDR’s with this tool than with many commercial ones.

This also means that mavens resource filtering is not very useful for individual assemblies, since you can only replace placeholders such as ${someValue} with the same value for all assemblies (since resources are only filtered once, using the active profile(s), for all assemblies).

You can, however, configure the maven assembly plugin to use individual filter property files for each assembly using the <execution> section of the plugin configuration, like so:

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <version>2.2-beta-5</version>
  <executions>
    <execution>
      <id>production</id>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${project.basedir}/src/main/assembly/production.properties</filter>
        </filters>
        <finalName>${artifactId}-production-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <phase>package</phase>
    </execution>
    <execution>
      <id>integration</id>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${project.basedir}/src/main/assembly/integration.properties</filter>
        </filters>
        <finalName>${artifactId}-integration-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <phase>package</phase>
    </execution>
  </executions>
</plugin>

This snippet uses the same assembly descriptor (you can use any assembly descriptor, actually) to build individual artifacts for production and integration. Note that the ${project.basedir}/ prefix is a workaround for MASSEMBLY-150 and is nedded to avoid a nasty Failed to create assembly: Error filtering file ... Error loading property file 'src/main/...' error when executing the mojo from outside the module directory (say, for instance, in a mvn release:prepare…).

Filtering must be enabled in the assembly descriptor, like so:

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/xsd/assembly"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/xsd/assembly http://maven.apache.org/xsd/assembly-1.1.1.xsd">
  ...
  <fileSets>
    <fileSet>
      <filtered>true</filtered>
      ...
    </fileSet>
  </fileSets>
</assembly>

Thanks to John Casey for suggesting this in MASSEMBLY-430!

The new design uses significantly less CSS and markup and increases the accessibility of the content. The design is also making use of the wider screen resolutions that became sort of a standard in the last years.

The image at the top is a scaled-up photograph of the Alps as seen from Bern, Switzerland.

Enjoy!
Olaf

java.nio.charset.Charset.defaultCharset()

So please don’t use messy, old workarounds such as this:

byte [] byteArray = {'a'};
InputStream inputStream = new ByteArrayInputStream(byteArray);
InputStreamReader reader = new InputStreamReader(inputStream);
String defaultEncoding = reader.getEncoding();

Which, unfortunately, is one of the first things you stumble upon when searching for this topic.

I myself suffered from the lack of support for recent integrated intel gfx cards in notebooks and thus followed the excellent Intel Linux graphics performance guide using the bleeding-edge configuration, i.e. with the latest (non-stable) builds of the xorg / intel gfx drivers and the most recent kernels. However, this configuration was (not quite unexpected) somewhat unstable and had a lot of issues.

This phase is now over. I am happy to say that after upgrading to Kernel version 2.6.32 and the xserver-xorg-video-intel driver 2:2.9.0-1ubuntu2~xup~3 the graphics support is now fast, reliable and stable. Desktop effects are back working like a charm, also in a multi-monitor setup and with sending the computer to hibernation and so forth.

I am quite optimistic that this state might make it into the upcoming Ubuntu release (Karmic), thus eliminating a lot of frustration laptop users have been experiencing with their intel gfx cards.

When working with enterprise integration you will quite often deal with legacy systems integration.

I recently had the case where integration of webservices was requested, and much to my surprise there are huge issues when attempting to integrate old webservices (as in pre axis2 and pre jax-ws).

These webservices use outdated or unsupported methods, such as rpc-style/encoded communication, or even worce, outdated elements in the XML messages, for instance <multiref>’s. Having to integrate such services does of course imply that you cannot change anything on the server side, and thus such an outdated format must still be consumed.
This is a huge problem, since current WS implementations, such as the popular axis2 framework, do simply not support these formats.

What surprised me the most about this is that webservices are designed to make systems independent by defining a common communication and data format, which is the exact opposite of what is going on here – and these formats are not that old, we are probably talking 4-5 years.

Developers facing these problems are taking rather desperate measures to work around these problems, such as using on-the-fly XSLT transformation to convert incoming and outgoing WS messages. However, this binds your application even stronger to the outdated format and specific service data.

In my case I wanted to use Spring-remoting. Since the service was RPC-style, I wanted to use the JaxRpcPortProxyFactoryBean to create an on-the-fly proxy implementing the service interface. What I did not want to do is having to write any additional code to consume the service. Furthermore, I wanted the complex objects transferred by the services to be represented by standard JAVA beans, and not be generated using the wsdl2java axis1 tools. Here is how I got this to work.

Using Spring-remoting’s jax-rpc support with axis 1

Required maven dependencies

First, I was willing to make the compromise of having axis1 on my classpath. This might not be the way to go for everyone, unless you are using an OSGI framework, which was not an option in my case. Using jax-rpc with axis1 from spring requires the following dependencies (I am using maven’s dependency management for the sake of simplicity):

<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>commons-discovery</groupId>
  <artifactId>commons-discovery</artifactId>
  <version>0.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-jaxrpc</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-saaj</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>wsdl4j</groupId>
  <artifactId>wsdl4j</artifactId>
  <version>1.6.2</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-aop</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-web</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib-nodep</artifactId>
  <version>2.2</version>
</dependency>

Note that this setup is for JDK 1.5. JDK 1.6 ships with quite a lot of jax-ws libraries, so you might want to check whether all of these dependencies are still required when using 1.6, but I fear they might.

Configuring the service using the port proxy factory bean

First, I downloaded the WSDL’s from the services and placed them within my src/main/resources folder to use them offline. This is not required, but I do recommend it. Next step was to set up the factory beans for jax-rpc to generate implementations of my service interfaces:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
    <property name="serviceInterface" value="my.package.MYServiceInterface" />
    <property name="wsdlDocumentUrl" value="classpath:path/to/my/wsdl.swdl" />
    <property name="namespaceUri" value="namespace/as/defined/in/wsdl" />
    <property name="serviceName" value="ServiceNameFromWsdl" />
    <property name="portName" value="PortNameFromWsdl" />
    <property name="servicePostProcessors">
      <list>
        <!--
          This is for mapping your POJO's to the complex service objects (if you are using any).
          You can use an arbitrary number of mapping <bean> configurations for every model
          namespace of your WSDL.
        -->
        <bean
          class="org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor">
	  <!-- encoding style as in WSDL, in my case the outdated soap/encoding -->
          <property name="encodingStyleUri" value="http://schemas.xmlsoap.org/soap/encoding/" />
          <property name="typeNamespaceUri" value="namespace/for/models/as/defined/in/wsdl" />
          <property name="beanMappings">
            <props>
              <prop key="my.package.MyPojo">ModelNameInWsdl</prop>
            </props>
          </property>
        </bean>
      </list>
    </property>
  </bean>
</beans>

If the service specifies an operation such as ComplexResponseVO getResults(ComplexRequestVO), you would thus define an interface like so:

public interface MyService {
     MyResponsePojo getResults(MyRequestPojo);
}

And map the MyResponsePojo and MyRequestPojo using the AxisBeanMappingServicePostProcessor in the above spring configuration. Spring will serialize and deserialize the pojos using standard getter and setter methods to obtain the values, thus you do not have to care for serialization or marshalling. In fact, your pojos do not even have to be Serializable.

Once you have this stuff up and running, you can inject the MyService implementation into any other spring bean and use it like any other bean. Spring will convert the usually annoying and unrecoverable RemoteExceptions into unchecked remote exceptions, thus if you want to handle these, catching remote access exceptions is recommended.

Using an interface as the service representation has the additional advantage that it is pretty easy to fake or mock the service for integration testing.

Handling uppercase data type attributes

Now it’s getting really ugly: Legacy services sometimes violate the JAVA standards of good coding and specify uppercase attribute names for their data types. This is like writing

public class MyService {
     private SomeType MyFieldName;
     ...
}

And thus pretty ugly. When using spring’s JaxRpcPortProxyFactoryBean things are getting a lot worce: the BeanDeserializer will look for a getter/setter pair (property) starting with an uppercase letter – and will never find it, since they must start with a lowercase letter. This is a known issue in Axis 1.x, and there is no fix released for it (and most likely there will never be one).

I solved the problem by providing a subclass of the org.apache.axis.encoding.ser.BeanDeserializer to the JaxRpcPortProxyFactoryBean using a subclassed AxisBeanMappingServicePostProcessor and a customized BeanDeserializerFactory:

<bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
...
  <property name="servicePostProcessors">
    <list>
      <bean class="my.package.MyServicePostProcessor">
      ....

Here is the sourcecode for this post processor, the deserializer factory and deserializer:

The post processor:

package my.package;

import javax.xml.namespace.QName;
import javax.xml.rpc.encoding.TypeMapping;

import org.apache.axis.encoding.ser.BeanSerializerFactory;
import org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor;

/**
 * This {@link AxisBeanMappingServicePostProcessor} registers a
 * {@link MyBeanDeserializerFactory} during
 * {@link #registerBeanMapping(TypeMapping, Class, QName) mapping registration}.
 *
 * @author Olaf Otto
 */
public class MyServicePostProcessor extends AxisBeanMappingServicePostProcessor {

  /**
   * Registers the {@link MyBeanDeserializer} for the given mapping.
   */
  @Override
  @SuppressWarnings("unchecked")
  protected void registerBeanMapping(TypeMapping mapping, Class javaType, QName wsdlType) {
    mapping.register(javaType, wsdlType, new BeanSerializerFactory(javaType, wsdlType), new MyBeanDeserializerFactory(javaType, wsdlType));
  }
}

The deserializer factory:

package my.package;

import javax.xml.namespace.QName;

import org.apache.axis.encoding.Deserializer;
import org.apache.axis.encoding.ser.BeanDeserializerFactory;
import org.apache.axis.encoding.ser.EnumDeserializer;

/**
 * This {@link BeanDeserializerFactory} provides a {@link #getGeneralPurpose(String) general-purpose}
 * deserializer {@link MyBeanDeserializer capable of handling local names not conforming to the java beans spec}.
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializerFactory extends BeanDeserializerFactory {
  private static final long serialVersionUID = -8880103201020594221L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializerFactory(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * Returns either:
   * <ol>
   *       <li>
   *           The super types general-purpose deserializer if the target type or
   *           the XML type is <code>null</code> or the pre-defined deserializer class
   *           is an {@link EnumDeserializer}
   *      </li>

   *      <li>A {@link MyBeanDeserializer} otherwise (standard case)</li>
   * </ol>
   *
   *  @return never <code>null</code>, rather throws a {@link RuntimeException}.
   */
  @Override
  protected Deserializer getGeneralPurpose(String mechanismType) {
    Deserializer deserializer;
    if (javaType == null || xmlType == null || deserClass == org.apache.axis.encoding.ser.EnumDeserializer.class) {
      deserializer = super.getGeneralPurpose(mechanismType);
    } else {
      deserializer = new MyBeanDeserializer(javaType, xmlType, typeDesc, propertyMap);
    }
    return deserializer;
  }
}

The deserializer:

package my.package;

import static org.springframework.util.Assert.hasText;

import java.util.Map;

import javax.xml.namespace.QName;

import org.apache.axis.description.TypeDesc;
import org.apache.axis.encoding.DeserializationContext;
import org.apache.axis.encoding.ser.BeanDeserializer;
import org.apache.axis.message.SOAPHandler;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;

/**
 * This {@link BeanDeserializer} takes care of non-normal local names,
 * i.e. local names starting with an uppercase character.<br />
 * Such a local name, usually derived from a WSDL description, will
 * lead to a property lookup for a getter/setter pair on the target bean of the deserialization
 * with an uppercase name start. However, all property names start with a lowercase character
 * according to the java beans spec, thus a property with an upper case name start
 * is never found, causing the deserialization to fail.<br />
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializer extends BeanDeserializer {
  private static final long serialVersionUID = 1183255594948119370L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc, Map propertyMap) {
    super(javaType, xmlType, typeDesc, propertyMap);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc) {
    super(javaType, xmlType, typeDesc);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * {@link #normalizeLocalName(String) normalizes} the localName and invokes
   * {@link BeanDeserializer#onStartChild(String, String, String, Attributes, DeserializationContext)}.
   */
  @Override
  public SOAPHandler onStartChild(String namespace, String localName, String prefix, Attributes attributes1, DeserializationContext deserializationcontext) throws SAXException {
    String normalizedLocalName = normalizeLocalName(localName);
    return super.onStartChild(namespace, normalizedLocalName, prefix, attributes1, deserializationcontext);
  }

  /**
   * Converts the first character of the local name to
   * {@link Character#toLowerCase(char) lower case}, if it is
   * {@link Character#isUpperCase(char) upper case}.
   *
   * @param localName must not be <code>null</code> and not empty.
   * @return The normalized local name, never <code>null</code>.
   */
  public String normalizeLocalName(String localName) {
    hasText(localName, "The local name must not be null or empty.");
    char localNameStart  = localName.charAt(0);
    String normalizedLocalName = localName;
    if (Character.isUpperCase(localNameStart)) {
      StringBuilder builder = new StringBuilder(32)
                    .append(Character.toLowerCase(localNameStart))
                    .append(localName.substring(1));
      normalizedLocalName = builder.toString();
    }
    return normalizedLocalName;
  }
}

You might also write you own Serializer if you have the problem “in the opposite direction” which, luckily, I didn’t.

Let’s hope the current WS standards are not deprecated this fast…

The best way of doing this avoiding endless recursion is to use apaches RedirectMatch rule, like this:


RedirectMatch ^/$ http://targethost/mywebapp


Easy, agreed. But i’ve seen (and done it wrong my self) quite often…

There was a hardware crash at the hosting center that has caused a complete exchange and re-installation of this server.
I’ve got older backups running now, recent posts are not up yet but will be within the next week.
Posts may still look crappy and outtakes may occur, but for now, a least the older stuff is back online…

Greetings
Olaf


[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists


If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.

This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:

Use the latest 2.x snapshot version of the maven release plugin and configure it to use remote tagging (on the subversion server) rather than tagging from your local copy.

You can do so by

1.) Adding the apache snapshots repository to your plugin repositories list

    <pluginRepositories>
        <pluginRepository>
            <id>apache-snapshots</id>
            <name>Apache Snapshot Repository</name>
            <url>http://repository.apache.org/snapshots/</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
        ...
    </pluginRepositories>

2.) Configuring the release plugin’s version and tagging

        ...
        <build>
        ...
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.0-beta-9-SNAPSHOT</version>
                    <configuration>
                        <tagBase>full url to the tags directory on the svn server</tagBase>
                        <!-- See http://jira.codehaus.org/browse/SCM-406 -->
                        <remoteTagging>true</remoteTagging>
                        <!-- Further non-mandatory but useful settings... -->
                        <preparationGoals>clean install</preparationGoals>
                        <autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        ...
        </build>
        ...

This fixed it for me.

Note: i had problems getting this to function with the scp:// protocol (provider) for my distribution repository. It seems logic, tough, that the choosen provider must support remote tagging, thus i choose the scpexe:// protocol (using a local scp executable) instead, that worked:

...
<distributionManagement>
<repository>
  <id>myReo</id>
  <name>myreo</name>
  <url>scpexe://...</url>
 </repository>
...
</distributionManagement>
...

Apparently, the upcoming 2.0 release of the maven-release-plugin will have remote tagging as default, so if you read this and the 2.0 version has been released, simply using it should do the job.