Thursday, October 29, 2009

Atlassian Dragon Quest, Day 3

Dragon Quest ^2 with more challenges the third day.

While I thought that it would be simple to drop in Bamboo, my setup presented me with some headaches.

Three times the container was going completely down (the downside of the all in one setup) during the Bamboo JIRA integration part.

I decided to tune up my memory settings, in particular
-Xmx1280 and
-XX:MaxPermSize=384m

So far this seems to have stabilized the system at least enough to finish the Quest and send in the Screenshot :)



Here is a shot of the memory graphs in Jira:


Looks good, but there is a lot of PermGen space that is likely to be taken up by the huge amount of classes.
I will try to shrink this moving identical libraries to be shared between all webapps.

However, I am still investigating the Exceptions, and will try to setup my own projects to exercise everything and see if it's a viable system setup to work with (kind of semi-test, semi-production).

Problems with the Bamboo Integration:
It's important not to forget to assign bamboo-admin to your user on crowd. This caused me a minor hiccup (I am already caching the SSO, so I had to start everything through).

Problems with the Bamboo Build:
Maven....maven....maven *argl*See http://bit.ly/12y5Xt Value 2, "Don't use maven", I can't agree more.

Hiccup in the black-box :) I followed through the forum, and installed the activation.jar by hand, then a manual build on the shell to make things work out.

One thing that also took quite some time, was to figure out how to configure a secure SMTP server as a resource in Resin 3.1.9. Ended up hacking the following class and packaging it in a jar into the ${resin.home}/lib directory

package net.wimpi.mail;

import javax.mail.Authenticator;
import javax.mail.PasswordAuthentication;

/**
* Extends the Authenticator to provide authentication
* for a session configured in the container configuration.
*/
public class SimpleAuthenticator extends Authenticator {

private String m_Username;
private PasswordAuthentication m_Auth;

public void setUsername(String username) {
m_Username = username;
}//setUsername

public void setPassword(String password) {
m_Auth = new PasswordAuthentication(m_Username, password);
}//setPassword

public PasswordAuthentication getPasswordAuthentication() {
return m_Auth;
}//getPasswordAuthentication

}//SimpleAuthenticator


The JNDI resource can be configured (I'd suggest to do it in the host's section, except you are going to use different servers for your different webapps):

<!-- Mail Server Resource -->
<mail>
<jndi-name>mail/ArimdiSmtpServer</jndi-name>
<authenticator type="net.wimpi.mail.SimpleAuthenticator">
<init>
<username>admin@yourdomain.com</username>
<password>********</password>
</init>
</authenticator>
<smtp-host>smtp.gmail.com</smtp-host>
<smtp-port>465</smtp-port>
<smtp-user>admin@yourdomain.com</smtp-user>
<smtp-ssl>true</smtp-ssl>
<init>mail.smtp.starttls.enable=true mail.smtp.auth=true mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory mail.debug=true</init>
</mail>


Also, don't forget to remove the activation and javamail jars from the WEB-INF/lib of Jira, Confluence, Bamboo and Crowd.

So far so good :)

Good luck to everybody: and remember, it's possible :)

Atlassian Dragon Quest, Day 2

Dragon Quest ^2 turned out as much of a challenge the second day.

Trying to squeeze everything into a single Resin 3.1.9 container makes things pop up every now and then, that need to be worked around. This time around I decided to read documentation first, putting the bits and pieces of information together to achieve:
  1. JIRA +SSO + GreenHopper
  2. Confluence +SSO
  3. Fisheye Setup +SSO
  4. Integrations JIRA-Confluence, JIRA-Fisheye
Most of day 2 turned out to be a joyful journey, so I will try to concentrate on the more challenging parts.

But before, some general recommendations for Resin:

Tune the container a little bit
It’s recommendable to tune the container a little bit, so you don't run into problems with memory and GC.
References:

I finally decided to use the following:
    <jvm-arg>-Xmx1024m</jvm-arg>
<jvm-arg>-XX:MaxPermSize=256m</jvm-arg>
<jvm-arg>-XX:+UseConcMarkSweepGC</jvm-arg>
<jvm-arg>-XX:+CMSIncrementalMode</jvm-arg>
Note: This is not a general recommendation; I'd really suggest to investigate and match these parameters to your specific needs and hardware.

Setup of JIRA
Following the some of the recommendations for JIRA 3, I modified the transaction factory attribute in entityengine.xml and switched the compiler:
 <javac compiler="javac" args="-source 1.5"/>
I also used the same isolated setup for the JAXP factories, using Xerces, Xalan and WoodStox. The only problem here is the fact that there is no Xalan in JIRA, but the plugin manager seems to require XSLT Transforms:

2009-10-28 12:08:29,852 main FATAL [atlassian.jira.upgrade.ConsistencyLauncher] A fatal error occured during initialisation. JIRA has been locked.
com.atlassian.jira.InfrastructureException: Error occurred while starting Plugin Manager. Provider org.apache.xalan.processor.TransformerFactoryImpl not found
at com.atlassian.jira.ComponentManager$PluginSystem.start(ComponentManager.java:1281)
at com.atlassian.jira.ComponentManager.quickStart(ComponentManager.java:224)
at com.atlassian.jira.ComponentManager.start(ComponentManager.java:210)
at com.atlassian.jira.upgrade.ConsistencyLauncher.launchConsistencyChecker(ConsistencyLauncher.java:63)
at com.atlassian.jira.upgrade.ConsistencyLauncher.contextInitialized(ConsistencyLauncher.java:42)
at com.caucho.server.webapp.WebApp.start(WebApp.java:1866)
To avoid the risk of problems with the Resin XSL Transformer, I decided to drop the Xalan jar into the JIRA webapp libraries. Problem solved :)

SSO and Greenhopper didn't cause any troubles, neither did Confluence, which came up on the first attempt (already applying most of the bits of information and experience with the rest of the bunch).

Sidenote (Critical):
I have one concern about Crowd Integration that I still need to investigate, which is the remote address. Using a home setup, I don't have a fixed IP address; however, I have configured a Dynamic IP Service, so that I can share my box anyway over the Internet. That said, somehow the clients always seem to resolve the actual IP address (the one that was assigned by the ISP), and this is going to cause me some major headaches if I am going to be suddenly blocked out of all my services because I was assigned a new IP.

Fisheye went straight as well, and to be able to integrate it fully, I am using a proxy webapp in Resin (so everything is nicely in place and no other servers are required). Note here that if you want SSO to work, you need to set trusted proxies in the Crowd Console -> Administration -> Trusted Proxies sidebar.

Setting up the integrations and gadgets in JIRA isn't really a big issue any longer, especially if you already have some experience with Atlassian Tools.

Time for "District 9" and some family life.

Farewell for today to all Dragon Quest participants.....and may the force be with you.

Tuesday, October 27, 2009

Atlassian Dragon Quest, Day 1 (Or how to make Crowd work in Resin 3.1.9)

Today I decided to start the Atlassian Dragon Quest in a modified version (don’t worry, it’s a challenge, not an ego trip). I’ll call it Dragon Quest ^ 2 (read squared): place as much as possible of these into a single webapp container. Maybe it won’t earn me a TShirt, but at least I am going to try and share some experiences on my quest.

This is day 1, and unfortunately I got stuck in my quest starting with base integration software piece “Crowd”. Given that I had a container up and running that I always wanted to try out with Atlassian, I decided to squeeze everthing into Resin 3.1.9 (made by Caucho).

After the initial steps, I was stuck without any log traces. Everything worked out, but the login didn’t work, and it didn’t report any problems. Time for reading some documentation...which led me to: Can't login into Crowd

However, entering my database, there was no domain set at all.

Another install cycle, same problem. Back to reading the docs...man sometimes it would be good to read the System Requirements before installing, right?

Resin versions 3.1.x and later are not compatible with Crowd. Please refer to CWD-1192.

Being a brave adventurer, there is no turning back once the quest has started, so I set out to find a fix for this problem.

Long story, short, Crowd uses XFire, XFire uses StAX and prefers WoodStox.....good that this is right in my field; it’s not just Xerces and Xalan we need to set, but also the correct factories for StAX, and voila! ;)

I left the workaround for the problem on CWD-1192, but unfortunately there were other problems lurking:
http://bugs.caucho.com/view.php?id=1530linkext7.yHw9doZrGRyK.jpg

So the struggle had to continue; fortunately the workaround is relatively easy. Large JSP’s can be split and imported. Doing so dynamically, will split the code and work around the problem of the Caucho JSP Compiler (well they say it’s a JDK limitation). So far the files that I split down are:
  1. /console/secure/principal/view_principal.jsp
  2. /console/secure/directory/add_directorydelegated.jsp
  3. /console/secure/directory.add_directoryconnector.jsp
I have also left these on CWD-1192 so others can enjoy Crowd on Resin 3.1.x ☺

It’s getting late, so I will call it a night, and continue my quest tomorrow. I hope that Atlassian follows up with a full QA to make Resin a better supported platform for Crowd (at the moment, lets see what more I can get up and running ☺).

Farewell to all the Dragon Quest participants...may the force be with you.