Setup WiFi (WPA2) connection on ubuntu via terminal

Edit:

/etc/network/interfaces

Add this: 

auto wlan0
iface wlan0 inet dhcp
wpa-ssid SSID
wpa-psk "password to wifi" 

Where: 

• wlan0 - name of the wireless interface 
• auto wlan0 - auto connect on start 

To connect manually run command:

ifup wlan0

Hibernate "import.sql" Encoding when Running Unit Tests in Maven

Ok, the title is quite horrible. The story goes like this: We have decided to use HSQLDB in memory database for our unit tests. It's just a matter of JDBC configuration. And when you tell hibernate to create your database (hibernate.hbm2ddl.auto=create), it looks for import.sql file that runs after database is created. If you have it, it can populate your database.
But if you use different than default platform encoding in your sql file, you may have troubles.

You must then set your encoding (-Dfile.encoding=UTF8). Sounds easy, but setting the encoding for Maven does not help. The trick is that maven-surefire-plugin runs in separate JVM.

So what I needed is just one more line:


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <configuration>
      <argLine>-Dfile.encoding=UTF8</argLine>
   </configuration>
</plugin>

XmlGregorianCalendar, what you get isn't what you want

Question: What you get when you do such thing?

variable calendar is an instance of XMLGregorianCalendar (year=2011,month=2,day=1, hour, minute and seconds are not set).

Calendar result = Calendar.getInstance();
result.clear();
result.set(calendar.getYear(), calendar.getMonth() - 1, calendar.getDay(), calendar.getHour(), calendar.getMinute(),calendar.getSecond());
result.set(Calendar.MILLISECOND, calendar.getMillisecond());

You might be thinking that you will get:

Year=2011
Month=1 (February)
Day=1
Hour, minute, seconds = 0

Be aware of doing this! While some field in gregorian calendar is not set then it's value is "-2147483648"

So, If you do such a conversion then you endup in 247120 years B.C.E ;-)


Solution:

use method:

calendar.toGregorianCalendar();

Implementation of this method:

if(month != -2147483648)
gregoriancalendar.set(2, month - 1);
if(day != -2147483648)
gregoriancalendar.set(5, day);
if(hour != -2147483648)
gregoriancalendar.set(11, hour);
if(minute != -2147483648)
gregoriancalendar.set(12, minute);
if(second != -2147483648)
gregoriancalendar.set(13, second);
if(fractionalSecond != null)
gregoriancalendar.set(14, getMillisecond());
return gregoriancalendar;

It's a kind of magic :-)

JAXB, Equals and hashCode methods

I have no need to have a equals and hashCode methods on generated java class yet but I need it now.

It is really simple. You have to use a specific jaxb plugin (in case of Maven) and plugins for this plugin ;-)

- Maven2 plugin: org.jvnet.jaxb2.maven2:maven-jaxb2-plugin
- configuration: -XtoString, -Xequals, -XhashCode
- plugin for Maven2 plugin: org.jvnet.jaxb2_commons:jaxb2-basics

While java classes are being generated this plugin hooks at the process and add equals and hashCode methods. My pom definition:

<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.7.4</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<clearOutputDir>true</clearOutputDir>
<extension>true</extension>
<schemaDirectory>target/schemas</schemaDirectory>

</configuration>
</execution>
</executions>
<configuration>
<args>
<arg>-XtoString</arg>
<arg>-Xequals</arg>
<arg>-XhashCode</arg>
</args>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>${version.jaxb2-basics}</version>
</plugin>
</plugins>
</configuration>
</plugin>

That's it!

JAXB, XJC and unmappable chars

Say we have a XSD contains documentation with special characters:

<xs:annotation>
<xs:documentation>Tady je použita čeština se vším všudy<xs:documentation>
</xs:annotation>

Once you setup maven build and "jaxb2-maven-plugin", goal "xjc" and let JAXB to generate Java classes according to your schema you may endup with following error:

unmappable character for encoding UTF-8

Well, you have schema in UTF8 already, you have setup maven build to use UTF8, so why it says that some characters are not in UTF8?

I've found solution described here.

Reason

com.sun.codemodel.writer.CodeWriter#openSource uses the OutputStreamWriter encoding to set the CharsetEncoder to use :

{ OutputStreamWriter bw = new OutputStreamWriter(openBinary(pkg,fileName)); (...) CharsetEncoder encoder = EncoderFactory.createEncoder(bw.getEncoding()); }

It SHOULD instead build a CharsetEncoder based on the user-requested encoding (may fallback to default platform encoding) and THEN create the OutputStreamWriter with this encoder...

{ CharsetEncoder encoder = EncoderFactory.createEncoder( getUserDefinedEncoding() ); OutputStreamWriter bw = new OutputStreamWriter(openBinary(pkg,fileName), encoder); }

Solution

You have to setup build to use native encoding for your OS.

I've added profile (for mac):

<profile>
<activation>
<os>
<family>mac</family>
</os>
</activation>

<properties>
<project.build.sourceEncoding>MacRoman</project.build.sourceEncoding>
</properties>
</profile>

java.util.logging over SLF4J

This year we have switched from log4j to SLF4J, using logback implementation of the "Simple Logging Facade" and jcl-over-slf4j and log4j-over-slf4j to deal with components that log using Jakarta Commons Logging and log4j respectively.
To have our collection complete, we thought it would be cool to include java.util.logging (JUL) - just in case some piece uses it.
Documentation says that there is a "jul-to-slf4j" module with a jul handler "that routes all incoming jul records to the SLF4j API". All you need is to call SLF4JBridgeHandler.install() once during application start-up.

The keyword here is "all". Once you register SLF4JBridgeHandler in your app, everything that gets logged via JUL in the entire JVM is logged in your app's log! I'd put the handler initialization into a servlet context listener and everything seemed to work fine - until I saw some puzzling messages in another web application that had the handler registered as well. And as long as I did not call uninstall, the messages multiplied with each application start as the number of handlers grew. You can imagine how perplexed we were since we though that the logged event really happens more than once (not that it only gets logged multiple times).

To call SLF4JBridgeHandler.uninstall() would not help anyway. A look at the source code shows that it removes all handlers that are instanceof SLF4JBridgeHandler. All from the entire JVM - for all web applications in our case.

To make the long story short, we have given up on "jul-to-slf4j". It can work only for a single application within a JVM and we cannot blame SLF4J here. There's something wrong with java.util.logging API all the way down.

Jáva Cimrman

Kolikrát jsme, jdouce ve stopách našeho národního velikána, museli pokorně uznat: Ano, vyfukováním cigaretového kouře do vody zlato nevznikne.
V tomto blogu se chceme podělit o konkrétní poznatky z vývoje serverových apliakcí v Javě, abychom i my lidstvu ukázali: "Tudy ne, přátelé!" A někdy snad i skromně: "Přátelé, tudy..."