Spring IDE copyright owner changed to GoPivotal...

I was quite surprised to when I opened the latest Groovy/Grails Tool Suite (GGTS) from SpringSource, the splash screen displays that the copyright owner of the Groovy/Grails Tool Suite. I believe it was previously VMware but i haven't checked it out again.

It turns out that VMware is spinning of the IDE, and teamed up with GE to setup this GoPivotal.

It's too early to comment, but it seems now the focus geared more toward monetizing the cloud platform.

Great products from Atlassian

I must admit that I've been a great fan of Atlassian, the company and its products. Great tools made for developers. Open source user, contributor and open source friendly company.
Great products, and they are Java based. Noone will ever say "Java is slow" (unless they stay in the caves, still hunting and gathering foods) when they have used Confluence or JIRA.

We used both  JIRA and Confluence at work.

I personally use Confluence for my personal content and knowledge repository.
I really liked it, just nice. Just as I need it. I can attach documents in it, version the document, attach pictures, etc. It's much better than folder or event some famous "document management". Of course only for my personal requirements point of view.

The other thing that I like is the architecture of the product, especially Confluence. It scales well, the search engine is based on Apache Lucene, it deploys stand alone on Tomcat, and also on many other application servers. It uses OSGi based on Apache Felix. So many good concept applied at the right spots. Another plus thing for me is, it supports PostgreSQL as one of the default databases for production. For me this is a big plus, as most of my personal production systems run on PostgreSQL.

Personally I think Confluence is much better structured (or architected) product than JIRA.

First, in term of the search engine, it's way much better. I don't know why JIRA couldn't have such good search capability as Confluence (e.g. it's difficult to find attachments or issues with attachments). Also the search completion as well.

Second thing is the backup and upgrade compatibility. After running for production a few years, it is so much easier to backup and restore Confluence, and it's much more difficult to backup and restore. Likewise the upgrade of versions.

Just from using such products I have learned so much for the products. Many items went into our products' wish lists... or at least my personal wish lists for our company's products.

PS: I am not related or getting paid by Atlassian. I am just a satisfied customer.

Single Sign On using Centrify DirectControl for Web and Tomcat

I was way too lazy to update my blog on Java. FYI, I am still working with Java <blink>.

Last month we have just successfully implemented a Single Sign On to Active Directory on one of our product. The Single Sign On was using Centrify DirectControl for Java/Web.
We are running on this stack:

1. Linux box for application server
1. JDK 6.0 update 31 (Centrify DirectControl requires JDK, not just JRE)
2. Apache Tomcat 6.0 (Tomcat 7.0 was not supported when we start implementing)
3. Centrify DirectControl 4.4.1-203
4. Centrify DirectControl for Java/Web 4.2.0-417
5. Red Hat Enteprise Linux 5.7 (when we started, it was still version 5.6, but now upgraded to 5.7 smoothly)
2. Active Directory
1. Windows Server 2003 or 2008
2. Active Directory 2003 or 2008
3. multi-domain forest with nested group of domain local, domain global, and universal.
4. global multi-site, replication over WAN.
3. Client
1. Windows XP Professional Service Pack 3, or Windows 7
2. joined one of the Active Directory domain.

Lots of people will associate Single Sign On with LDAP. Though LDAP most likely being involved somewhere in the Single Sign On, not every systems that use LDAP are using Single Sign On. In fact, those are just shared username/password hash database systems.

This is what I mean: if you have to login again inside your browser, definitely it is not a real Single Sign On system we are talking about.

What we implement is when you have successfully logged in to your desktop (in this case Windows XP or Windows 7), whenever you open your browser pointing to the correct URL, the web application will recognize you as the user you have logged in to Windows Active Directory domain.

We came into Centrify DirectControl because it is desired by the customer's infrastructure team for systems that run on Linux boxes.

What we learned from this implementation:

1. Implementing Single Sign On with Centrify DirectControl needs some paradigm change to the user and group that we already implemented.
2. So far Spring Security Single Sign On (Kerberos) to Active Directory that we tried only works in the lab of those who play with it, but is very difficult to replicate everywhere else. We eventually ditch our beloved Spring Security component in order to implement using Centrify DirectControl. This may change in the future, but we spent considerable amount of time without being fruitful on it.
3. On the other hand, the Centrify DirectControl for Java/Web works the first time we tried it. The sample just works.
4. Modifying the sample of Centrify DirectControl for Java/Web to a real world Single Sign On is not a trivial task though. In the instance of our client, many have tried and gave up, and we were the first one to successfully implemented it using Centrify DirectControl for Java/Web.
5. In the development site, make a working environment of Active Directory server, Active Directory client and a Linux server box is not so trivial, due to many factors that can make it fail.
1. Get the DNS setting correct is the key to successful setting of the environment.
2. Use of the tools to really diagnose, don't ignore slight problems that occurs as error messages.
6. Among of those issues that we encountered:
1. If something is wrong with the Single Sign On, usually you won't see any messages.
2. It is difficult to get the Java logging to display something the first time.
3. The forced use of old commons-logging 1.0 by CentrifyDC caused a lot of problems (we have to resolve the logging conflicts to get it working, yet because it is logging problem they won't tell you anything).
4. When you want to create installer that doesn't depend on CentrifyDC web installer, you have to really trace the dependencies one by one.
5. Some problems were caused by propagation delay or caching of Active Directory/Centrify DC/Kerberos data which simply just need to wait and try again. We encountered this several times in different places, e.g. adding user to new group but not recognized in the header, after waiting for (few) hours, it suddenly became working like magic. Yes, we tried to restart everything, leave and rejoin domain, and still the stubborn caching didn't flush at all.
6. Tomcat has unusually small default maximum HTTP header size, this kind of SSO requires bigger HTTP header size. According to our friend this also happened before with other SSO on Windows/IIS.

Model 2 Code Eclipse

This www.model2code.com site is offering an affordable, agile and model driven Eclipse based tool that is able to forward engineer from model to application. I want to give it a try (it's a trial application).
The size is quite a fat download (more than 1GB!) and unfortunately today's Internet connection is slow here.

The incoming Spring 3.1 will have annotation based cache

I think this is one of the feature developers are waiting for.

I remember last time when my colleague have to implement our specific annotation to incorporate OSCache into the web layer. Now it will be as simple as adding annotation to existing Spring beans!

http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/

Singapore JUG Meetup January 2011

Next Java User Group Singapore Meet Up will be scheduled on January 25th 2011.
I posted the announcement at meetup.com, Facebook and also Twitter. Hopefully that will reach some people who really keen to it.

We are still looking for a good venue, and may be some figure on how much people will attend will help to find a suitable place for this meet up.

Ruslan Khafizov has been volunteered with the idea: "Fluent Interface in Java".
Anyone suggests place to meet somewhere in central Singapore?

Trying to revive the Java User Group Singapore Meet Ups

Java User Group Singapore has been quite inactive for a while (last meet up was 189 days ago, according to meetup.com). I attended some of the meet ups in the past, but not recently because of the coming of our newborn baby. I guess a lot of people were also busy with their own things :O

Lots of changes happened, we can no longer use the Sun Microsystems office at Central Mall, 1 Magazine Road, Singapore. The office apparently had been shut down due to the consolidation after the acquisition by Oracle. The last 2 meetings were held at Hackerspace, 70A Bussorah Street, Singapore.

We want to revive the meet ups of Java User Group Singapore again.
I was thinking, probably the first month of next year will be best time to start, as December is too close and most people will be off in holidays during mid-December to mid-January.

Today I met one Oracle employee. He wants to pass me the contact person who's in charge of maintaining relationship with developers. We of course welcome anyone or companies who can provide place for meet ups. Ideally the place should be located somewhere central.