Continuous Integration - JENKINS

Jenkins Installation:

Automatic Installation:

1. To use repository, run the following command:
    $ sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
     $ sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

If you've previously imported the key from Jenkins, the "rpm --import" will fail because you already have a key. Please ignore that and move on, with that set up, the Jenkins package can be installed with:

    $ yum install jenkins

Manual Installation:

1. Download Jenkins[http://pkg.jenkins-ci.org/redhat/] latest version jenkins-1.535-1.1.noarch.rpm

2. $ rpm -ivh rpm -ivh jenkins-1.535-1.1.noarch.rpm as root user. If not root you will receive exception : [error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)

     rpm -qa | grep -i webmin

     rpm -e <package name>

     /etc/sysconfig/jenkins saved as /etc/sysconfig/jenkins.rpmsave

3. Re-install latest package:

     [root@cmputl-dt-4d jenkins]# rpm -ivh jenkins-1.535-1.1.noarch.rpm

      warning: jenkins-1.535-1.1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID d50582e6: NOKEY

      Preparing...                ########################################### [100%]

      1:jenkins                ########################################### [100%]

4. Check Configuration at vi /etc/sysconfig/jenkins

      JENKINS_HOME="/var/lib/jenkins"

      JENKINS_JAVA_CMD=""

      JENKINS_USER="jenkins"

      JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"

      JENKINS_PORT="8080"

      JENKINS_LISTEN_ADDRESS=""

      JENKINS_HTTPS_PORT=""

      JENKINS_HTTPS_LISTEN_ADDRESS=""

      JENKINS_AJP_PORT="8009"

      JENKINS_AJP_LISTEN_ADDRESS=""

      JENKINS_DEBUG_LEVEL="5" # 1 -9

      JENKINS_ENABLE_ACCESS_LOG="no"

      JENKINS_HANDLER_MAX="100"

      JENKINS_HANDLER_IDLE="20"

      JENKINS_ARGS=""

5. Jenkins Startup Script: /etc/init.d/jenkins.

1. Jenkins will be launched as a daemon up on start. See /etc/init.d/jenkins for more details.

2. The 'jenkins' user is created to run this service.

3. Log file will be placed in /var/log/jenkins/jenkins.log. Check this file if you are troubleshooting Jenkins.

/etc/default/jenkins will capture configuration parameters for the launch.

4. By default, Jenkins listen on port 8080. Access this port with your browser to start configuration.

If your /etc/init.d/jenkins file fails to start jenkins, on line 108 you may change su -l <username> -c <command> with sudo -u <username> <command>. This fixed init.d script for me (icarito, July 2013).

6. Run: service jenkins start as root to start the instance, once service is started you can see jenkins instance running at "http://cmputl-dt-4d.ula.comcast.net:8080/".

7. Download plugin[https://updates.jenkins-ci.org/download/plugins] and place them under <jenkinsHome>/plugins/ directory. Sometimes when you download plugins you may get (.zip) files then just rename with (.hpi) and then extract all the plugins and move to <jenkinsHome>/plugins/ directory.

/var/lib/jenkins/.ssh/id_rsa

WAR Installation: 

refer here

I don't remember my Jenkins password. How do I change it?

Issue: When creating a Jenkins application, the client (Web Console or rhc client) will print the admin password for your new Jenkins instance as well as recommend that you change it. The password, however, will not be stored in any environment variables.

Resolution: If the password is lost/forgotten, there are a few ways around it.

1. Since this is your own Jenkins instance, and you know there have been limited customizations that you can recreate, just destroy the Jenkins app and recreate another.  A new password for your new Jenkins instance will be set and printed to your client.  Don't forget to remove/re-add the jenkins-client-1.4 cartridge to those applications that you want Jenkins to help build and test.

> rhc app delete -a jenkins

> rhc app create -a jenkins -t jenkins-1.4

> rhc cartridge remove jenkins-client-1.4 -a {appUnderTest}

> rhc cartridge add jenkins-client-1.4 -a {appUnderTest}

2. ssh onto the gear and set the user password.  Since this is done with a hashcode, you can hand-set it to 'admin' with the following hashcode in file ~/jenkins/data/users/admin/config.xml:

 <passwordHash>oxulLC:aa38a78fabb46033263e7aa7bd2446d627ff4651e3c99eb1b6fc226f704cbc03</passwordHash>

Then you can proceed to login with admin/admin and alter your password at: https://jenkins-{yourDomain}.rhcloud.com/me/configure

3. ssh onto the gear, disable authentication, set the password via the Jenkins Web UI, then enable authentication:

- ssh onto the gear

- backup your config.xml

> cp ~/jenkins/data/config.xml ~/jenkins/data/config.xml.bak

- modify: ~/jenkins/data/config.xml from <useSecurity>true</useSecurity> to <useSecurity>false</useSecurity>

- remove the tag block: <authentication strategy>

- restart jenkins with "ctl_app restart"

> NOTE:  at this point, jenkins is not secure.  

- access Jenkins instance with browser and modify the admin password.

- copy backup of config.xml:

> cp ~/jenkins/data/config.xml.bak ~/jenkins/data/config.xml

- restart jenkins

Trouble logging in as jenkins (centos that rpm install created) user after changing password

1. What happened was that my user was not part of AllowUsers within the /etc/ssh/ssh_config file. Adding that user and restart sshd healed the pain.

2. The Jenkins RPM install creates the dedicated user a no-login user, with /bin/false as the default login shell. To fix this, do
$ sudo usermod -s /bin/bash jenkins and then check this with
$ grep jenkins /etc/passwd which should show bash, not false. After setting the default shell to allow the jenkins user to log in, be sure to assign a password with
$ sudo passwd jenkins and provide the new password at the prompt.

Java Logging Framework(s)

Logging, which framework to choose? Log4J, Commons Logging, LogBack, SLF4J?
Logging is part of every application we create and most of the time we do not use java’s own Java Util Logging framework. Most developers and architects use Jakarta Commons Logging (JCL) in combination with Log4J. But what about SLF4J instead of JCL? Although more and more frameworks are using it, a lot of developers and architects stick to Jakarta Commons Logging with Log4J, why is that?

Ok, lets first go through the actual logging frameworks. After that we can decide which facade we are going to use.

Log4J:
Log4J has become the defacto standard implementation for logging, since it started of as a framework for logging since Java did not include a logging facility itself. It seems every developer knows it and most projects and application servers use it. So probably I do not need to tell you about the logging levels TRACE, DEBUG, INFO, WARN and ERROR. The fact that you configure the layout of the messages containing date and time, thread, class and method information. The availability of file, database and e-mail appenders is also widely known and used. In short, this is the logging framework.
However, Log4J is not actively maintained anymore. It is widely spread and stable according to the v1.2 website. Log4J was the pioneer framework that introduced configurable logging. Introduction of the logging level, the logger and the appenders, it’s all the guys that developed Log4J who came up with that. But now it is stuck in its implementation and no-one seems to be willing to create a new and improved v2.0.

Java Util Logging(JUL):
Java introduced its own logging framework to make logging more configurable then the previous usage of  System.out.println(), System.err.println() and e.printStackTrace() usage. However instead of perfecting the allready introduced Log4J framework, it introduced a similar but not finished API. Java Util Logging is not very developer  friendly. It contains just a very basic way of logging, a method called log where you always have to indicate the level. And those levels are not very clear for usage (SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST).
So basically, I would not choose this as my logging framework.

Log Back:
LogBack is kind of what should have been Log4J 2.0. It picks up where Log4J stopped. The creator of Log4J also started the LogBack project to create a new and improved version.
LogBack’s internals are refactored to be faster, have a smaller memory footprint is better tested and has good documentation. All improvements that we welcome. LogBack also implements the SLF4J API natively and can easily be used as a dropin replacement for Log4J (at least that is what they say, I will definitely need to try that).
LogBack has some other cool new features, like the SiftingAppender, which is able to separate your logfiles on for instance a user session. It is also possible to change the loglevel only for a certain user, so you can troubleshoot a production problem without the logfile eating up your limited diskspace!
I/O failover is better, whenever a file server fails temporarily, you do not need to restart your application to start logging again.
The configuration file is automatically reloaded upon modification, a nice feature for application servers and JEE applications. Another nice addon is the logback-access module for application servers. This addon adds the ability to see HTTP-access logging to your application.
There is also the logviewer Lilith, comparable to Chainsaw for Log4J, but it can handle large logfiles much better.
When logging it is a best practice to check the level (when using commons logging and/or Log4J) using code similar to this:

if( logger.isDebugEnabled() ) {
  logger.debug( "User with account " +
    user.getAccount() + " failed authentication; " +
    "supplied crypted password " + user.crypt(password) +
    " does not match." );
}

Within LogBack it would be much simpler, more readable and cleaner. The previous example would look like this:

logger.debug( "User with account {} failed authentication; " +
    "supplied crypted password {} does not match.",
    user.getAccount(), user.crypt(password) );

While writing down all these features, I wonder why we are all still using Log4J. I will need to look into this framework soon!

Logging Implementation Choice:Basically, Log4J is the defacto standard and the default choice. I definately want to take a look at LogBack, but for now I would still go for the ‘safe’ choice Log4J.

Looking into the facade frameworks Jakarta Commons Logging and SLF4J, what should we use here?
Jakarta Commons Logging:
Jakarta Commons Logging creates an API that hides the real logging framework. Since there are a lot of logging frameworks (Avalon LogKit, Log4J, JUL), Commons Logging tried to create an API so developers could switch logging framework without recompiling the code.It is widely spread. Frameworks like Spring also use it, although other frameworks like Hibernate have changed to SLF4J recently.Commons Logging is not actively maintained anymore, but is stable. One very big downside often encountered is class loader issues in application servers.

SLF4J(Simple Logging Facade For Java):
SLF4J is not a logging implemenation, like Jakarta Commons Logging, it is just a facade to provide logging functionality in an application without to much hassle with dependencies. However, SLF4J is a cleaner dependency and more efficient at runtime than commons-logging. One of the reasons is SLF4J uses compile-time bindings instead of runtime discovery of the other logging frameworks it integrates. That means that you cannot switch logging implementations at runtime (and who would want that?). You configure which of the common logging frameworks you want to use explicitely.
Another difference with Commons Loggins is that it does not only provide bindings to many common logging frameworks, including JCL, it also does the reverse. SLF4J includes bridges between other logging frameworks and itself. OK, but what does that mean, well if you want to use SLF4J with for instance Spring which uses the commons-logging framework, you will need to replace the commons-logging dependency with the SLF4J-JCL bridge. Once you have done that then logging calls from within Spring will be translated into logging calls to the SLF4J API, so if other libraries in your application use that API, then you have a single place to configure and manage logging.
When bridging from Spring to SLF4J, you could choose Log4J as the binding, which would result in 4 dependencies (and off course the exlusion of the commons-logging dependency of Spring): the bridge, theSLF4J API, the binding to Log4J, and the Log4J implementation itself. Therefore most people using SLF4J choose LogBack instead of Log4J. That requires only the bridge jcl-over-slf4j and logback (and exclude slf4j-api from dependencies that include that!).

SLF4 nicely decouples API from implementation so that you can use the API that works best with your development with the back-end that suits best your production team. For example, you could enforce the use of the SL4J API while letting the production still reuse the old log4j.properties they’ve known for ages. SLF4J’s logging implementation is known as LogKit.
SLF4J Bridging:SLF4J has a bridging feature sor you can remove all log4j and commons-logging dependencies from your project’s dependencies and use only SLF4J.
SLF4J offers a JAR for each logging framework: they mimic its API but reroute the calls to the SLF4J API (which in turn uses the real framework). A word of warning: you could run into a cycle so beware to not have the bridging library along the implementation library in your classpath. For example, if you use the Log4J bridge, each Log4J API call will be rerouted to SLF4J. But if the SLF4J Log4J implementation is present, it will be routed back to Log4J then again, and again.
SLF4J API with Log4j Implementation:Taking all these facts into account, my advice is to use SLF4J API and Log4J implementation. This way, you still configure logging the old Log4J way but you have access to SLF4J’s simpler API. In order to do so, you’ll have to:

Action	Location	Description
Add to classpath	slf4j-api.jar*	Main API without which you cannot use SLF4J
	slf4j-log4j.jar*	SLF4J Log4J implementation
	jul-to-slf4j.jar*	Enables rerouting JDK 1.4 logging calls to SLF4J
	jcl-over-slf4j.jar*	Reroutes commons-logging calls to SLF4J
Remove from classpath	commons-logging.jar*	Would conflict with commons-logging API in jcl-over-slf4j.jar
SLF4JBridgeHandler.install()**	Main application	Redirect JDK 1.4 logging calls to SLF4J
* Jar name will likely includes version
** 20% overhead advertised so do only if you need the single entry point and if there are a few calls

Conclusion: During my research for this article I encountered the LogBack logging framework. I had heard of it, but just like any architect, I used what I already knew. But having looked into it, I think it is definately worth a shot to see what happens when I encorporate it into my applications. Will it work in application servers like IBM Websphere and JBoss? Or does it only work on development containers like Tomcat and Jetty? How much conflicts do I need to solve with Maven since a lot of dependencies will use JCL and assume it is there? For now, I will leave it at that and assume we are still using good old Log4J as the implementation framework and focus on the choice between Commons Logging and SLF4J.
Jakarta Commons Logging is widely spread, used by the very popular Spring Framework and in recent release of application servers it is shipped with the application server. So the easy choice would be Jakarta Commons Logging.
Depending on the time pressure and team composition I would probably choose JCL first. Maybe it is the anxiety for the unknown and unused, but in my experience the possible deployment issues could be a killer for a project when using ‘new’ technology like SLF4J and LogBack.
When time is not as important, but performance is, I would definately try to use SLF4J with LogBack. Another reason to use SLF4J with LogBack would be when there are certain requirements that can be met with the improved appenders.

Advantage of SLF4J:

• No bloated code since we do not need the if(logger.isDebugEnabled()) line anymore to prevent sting concatenation. (Note that other expensive calls made in the log statement might force us to put the if statement back!)
• Parameterized logging, easily markup your logging message and pass the arguments.

Disadvantage of SLF4J:

• Classloading problems when application servers still use Log4J and ship commons logging and Log4J libraries in their own server lib directory. Use reverse class loading (IBM calles it ‘parent last’) to let your application determine the logging framework.
• Some maven plugins use commons-logging which then cause conflicts.
• Need two libraries as dependency, one for bridging to slf4j and one for the actual implementation.

References:
FACADES: SLF4J | COMMONS-LOGGING
Implementation: LOG4J | LOGBACK
Issues: Commons Logging Classloader Issue

Accepting a Job Offer? Ask These 10 Questions First

Not quite. You're not on Easy Street yet. While the bulk of the heavy lifting of applying and interviewing is behind you, a few crucial steps remain before your first day on the job.

Two important phone calls will likely occur before the deal is sealed: The first, in which you'll be offered the job, and the second, when you either accept or decline the offer.

The Offer: When you're initially offered the job, don't automatically accept-even if you're thrilled to have received the offer. Remain composed, and make sure you ask the three following questions during the first call.

---

Q. When do you need an answer by?
Explanation: Always ask how many days you have to make your decision. You should be given at least a 24-hour buffer to think over an offer. This gives you time to think about follow-up negotiating questions. "Also, by asking this question, you're signaling that you may want to discuss the offer, so they'll be expecting your negotiation to come".

Q. Can I receive a copy of the offer and the benefits package?
Explanation: In the flurry of excitement that accompanies a job offer, I says sometimes candidates forget what the actual offer is. Make sure you request a follow-up email with the job title, the annual salary, and a complete copy of the benefits package.

Q. If I have questions about the benefits package, who should I speak with?
Explanation: If you receive an offer from your potential boss, he may not be able to help with questions about dental and vision plans, for example, so find out whom to direct your questions to (perhaps someone from the human resources department).
The Negotiation: Once you've thought over your follow-up questions, call the person who extended the offer (whether it's your potential boss or HR) and ask away. Prioritize your questions-if you're happy with the salary, there's no need to negotiate that point. If you're concerned about flextime, ask about that instead.

Keep in mind that this conversation needsto happen on the phone-not through email. "Emails come off more demanding than you'd think," says James Chopra. "If an employer opens up an email and sees a list of questions, they will get put off. Also, the speed of their answers gives you an indication of where you have negotiating room, but you can't tell that through an email." That said, below is a list of questions to consider asking about your offer:

Q. When is the start date?
Explanation: Make sure you're on the same page concerning your start date. The employer may think you can start ASAP, but you may need to give two weeks' notice to your current employer or need more time to relocate.

Q. Is the salary negotiable?
Explanation: If you're unhappy about the salary, now is the time to negotiate. If the person you're speaking with hesitates when you ask if the salary is open for discussion, there's probably room to negotiate a higher salary. If the response is a quick, firm "no", you need to decide whether you want to settle for it. Now is also the time to ask about a signing bonus.

Q. What are the core hours?
Explanation: Make sure you know what daily schedule you're getting into. Is the typical workday 7 to 4 or 9 to 5? Figure out whether you'll be working 40, 45, or 50+ hour weeks.

Q. Who will I be reporting to?
Explanation: You should have already covered this in the interview, but make sure you know who your boss is. Supervisors can make or break a job, so you want to make sure you can get along with yours.

Q. Can you confirm that I will have the opportunity to telecommute or work on a flextime schedule as we discussed in the interview?
Explanation: The key phrase in this question is "as we discussed in the interview." Avoid springing it on your employer that you want to telecommute every Tuesday and Thursday or work four 10-hour days instead of five eight-hour days. However, if this is something you discussed in the interview, you should confirm that it stands as part of the offer.

Q. Will the company help me with my moving expenses?
Explanation: If you need to relocate for your job, this is a required question. The company may offer to pay for your movers, which can relieve the financial burden.

Q. Can I have all this in writing?
Explanation: After wheeling and dealing to get the perfect offer, ask to get a confirmation of everything you negotiated, even if it's just an email that sums up the modified offer. If you're happy with the offer agreed upon over the phone, accept it before relocating or quitting your current job.

- Have fun :)

---

Java logging vs Apache's Commons logging

Here's a comparison between the java logging system and apache commons logging system.

For the lazy ones here's the conclusion:

• Commons Logging Rocks!
• Java Logging Sucks!

Why ? Well because:

• Commons Logging api is better
• Commons Logging let you choose your logging implementation
• Commons Logging is bulletproof, production ready, heavily use everywhere
• Everybody knows Commons Logging

Not convince yet ? Good I like people that don't take things for granted easily ;)

Let's compare the 2 frameworks api:

Java Logging	Commons Logging
Unclear log level: SEVERE > WARNING > INFO > CONFIG (wtf?) > FINE > FINER > FINEST (missing some imagination here ?!)	Clear log level using different names: FATAL > ERROR > WARN > INFO > DEBUG > TRACE
No ERROR level! I find it really disturbing especialy since there is a System.err stream for so many years	There is an ERROR level
To log an exception: logger.log(Level.SEVERE, e.getMessage(), e); or may be logger.log(Level.WARNING, e.getMessage(), e);. Unclear what Level to use and why do I need to do e.getMessage() it could have been done in the log() method. Missing simple methods: logger.warning(Throwable t) and logger.severe(Throwable t)	To log an exception: logger.error(e);
To configure either modify the logging.properties in your JRE/lib folder or set -Djava.util.logging.config.file=/my/folder/logging.properties No way to put a conf in the classpath to be automaticaly pick up by the logging framework	Possibility to put an already configured conf file
Create a logger: private static Logger logger = Logger.getLogger(MyCLass.class.getName()); Missing method: Logger.getLogger(class)	Create a logger: private Logger logger = Logger.getLogger(getClass());

The good things about Java Logging:

• Classloader: About the configuration part the way java logging does the configuration is less flexible but might reduce classloader problems that you encounter with commons logging (see: Commons_Logging_FUD)
• No jars to add, No additional dependency.

Working with Commons Logging api is some much better, simple and easier that I will continue to put those 2 jars in the classpath whenever possible if that's what it takes to use it.

 Reference: Common's Logging Implementation.