Thursday, 11 August 2011

Eclipse doesn't shut down the process after exit

Another issue that I solved today was regarding closing Eclipse. After migrating to 64bit Ubuntu, my Eclipse (newly installed) didn't want to close. After closing, eclipse continued to run in background. In fact when I noticed it, I had 3 or 4 running eclipse processes since plugin installation requires restarts and each restart added one process eating all swap space. There was no evidence in GUI of running processes, but process manager did show them running. Then i came across this bug in launcpad and it did solve the problem.

Solution: Disable assistive technologies: System > Preferences > Assistive Technology Preferences > "Enable assistive technologies"

Dual monitors in LXDE

Trying out LXDE as my desktop environment on ubuntu box (Gnome is getting easy to use, but too heavy). There were some problems with dual monitor support (couldn't find a config app), but this line solved everyting:

xrandr --output VGA-0 --auto --left-of DVI-0

Inspired by this blog post.

Friday, 15 April 2011

I18n portlets

Supporting multilingual content is very important in my organization. Unfortunately not everything is so easy as it might seem. Today I solved a little problem which was bugging probationer who is under my guidance. As it turned out, there were two major problems with this tutorial:

  1. He was using wrong fmt.tld file. The best thing is to define taglib using this line (notice the difference from line in tutorial):
    <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
  2. Ssecond pitfall was that uPortal implementation which we use, didn't set locale automagically. If your portal implementation isn't setting this attribute (with key 'javax.servlet.jsp.jstl.fmt.locale'), then use these lines (the first one is needed in order to define renderRequest value):
    <portlet:defineObjects />
    <fmt:setLocale value="${renderRequest.locale}"/>

Ok, now putting all together if you need to translate content in JSP:

  1. Check that your portlet supports locales of your choice
    <portlet>
    ...
    <supported-locale>en</supported-locale>
    <supported-locale>lv</supported-locale>
    ...
    </portlet>
  2. Create files named messages.properties and messages_lv.properties in package com.example with key-value pairs of your choice. For example:
    messages.properties:
    welcome=Welcome to my page!

    messages_lv.properties:
    welcome=Esiet sveicināti manā mājas lapā!
  3. Add standard library to classpath of your web application (i.e. in WEB-INF/lib) and define use of formatting taglib in JSP page, specify locale, and translate:
    <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
    <%@ taglib prefix="portlet" uri="http://java.sun.com/portlet" %>
    ...
    <portlet:defineObjects />
    <fmt:setLocale value="${renderRequest.locale}"/>
    <fmt:setBundle basename="com.example.messages"/>
    <h1><fmt:message key="welcome"/></h1>

Hope this helps

Thursday, 7 April 2011

Trusting self signed certificate in java

Simple version of how to trust self-signed certificates.
$ wget https://raw.githubusercontent.com/escline/InstallCert/master/InstallCert.java
$ javac InstallCert.java 
$ java InstallCert host:port
$ cp jssecacerts /usr/java/jdk1.6.0_21/jre/lib/security/

restart JVM and you're done. Of course, you can always choose longer path and follow JSSE documentation

Thursday, 24 March 2011

Trusting self-signed certificates

Yesterday I worked on a task that involved changing user password in Active Directory. Changing users pasword in AD requires secure connection (636 port) and self signed certificate was used (it was a test machine after all). I knew that Java won't accept that certificate, but was surprised that even Luma didn't accept the certificate, hence started looking over google to find a solution. Surprisingly nothing came out. There were tons of materials describing how to create a self signed certificate, but nothing how to accept one. After a couple of hours I remembered that one internal project documentation described the thing i needed. Steps:


  1. openssl s_client -connect ad.example.com:636
  2. Copy the certificate (everything between lines 'begin certificate' and 'end certificate' including both lines)in file (e.g. ad-example-com.cert)
  3. keytool -import -alias ad-example-com -file ad-example-com.cert -keystore ad-example-com.keystore
  4. Add certificate and keystore file to Luma (in server configuration view) and now you should be able connect to AD without problems...

In order to connect to AD using Java and accept SSL connection, use see this blog entry (by Andreas Sterbenz). InstallCert java file attached to his blog post is very easy to use in order to create jssecacerts file which can be copied to $JAVA_HOME/jre/lib/security in order to accept the self signed certificate.

Monday, 14 March 2011

Hibernate and native SQL fetching

Today it took me about 3 hours to find a problem in my code that was caused by HHH-2831. Unfortunately Hibernate documentation is vague regarding 'return-join' elements. By reading comments of bug, i realized that i'm not the only one facing the same problem and in all cases it was intuition of developers which proved to be wrong.

I'll explain briefly the essence of problem. Consider two simple hibernate class mappings and named native SQL query:

  <class name="ObjectA" table="OBJECT_A">
<id column="ID" name="id">
<generator class="native" />
</id>
<property name="title" column="TITLE" type="string" length="255" not-null="true" />
<list name="children" cascade="all-delete-orphan">
<key column="OBJECT_A_ID" not-null="true" />
<list-index column="ORDER_INDEX" base="0" />
<one-to-many class="ObjectB" />
</list>
</class>
<class name="ObjectB" table="OBJECT_B">
<id column="ID" name="id">
<generator class="native" />
</id>
<property name="title" column="TITLE" type="string" length="255" not-null="true" /> </class>
<sql-query name="getAll" read-only="true">
<return alias="a" class="com.example.ObjectA" />
<return-join alias="b" property="a.children" />
select {a.*}, {b.*}
from OBJECT_A a
inner join OBJECT_B b on b.OBJECT_A_ID = b.ID
</sql-query>

Now... what do you expect of when executing something like:

List result = session.getNamedQuery("getAll").list()

I was expecting it to be a list of objects of class ObjectA without any duplicates. Unfortunately this is not the case (like it would've been when using HQL). In fact it returns a list of Object[2] elements and with as many duplicates of ObjectA as it has children. The second object in array is ObjectB (child) object. Hence you must filter the list for duplicate elements:

        List finalResult = new ArrayList();
for (Object[] objs : result) {
ObjectA obj = (ObjectA) objs[0];
if (!finalResult.contains(obj)) {
finalResult.add(obj);
}
}

I wonder what will happen in case of another level... They cannot be filtered if those collections are not inverse, because it would automatically update the list of children (remove them).

Thursday, 10 February 2011

UTF-8 encoding with nusoap

Again problems with UTF-8 encoding. This time it's related to nusoap. I hate when developers assume that everyone uses english by default. Everyone should use UTF-8 by default. But now to the point...

When submitting a request to nusoap-based web service (nusoap_server), it assumes that characters ar encoded using ISO-8859-1. In fact very first search made by Google with keywords "nusoap utf-8" showed me the right path, but since this is my notebook, i'm writing down to remember: When creating web service, you must tell nusoap to not decode utf8 since encoding is utf8 already (see code snippet below).


$server->configureWSDL('myWebServiceMethod', $namespace);
$server->wsdl->schemaTargetNamespace = $namespace;
$server->decode_utf8 = false;