Updating a JAR File

The Jar tool provides a u option which you can use to update the contents of an existing JAR file by modifying its manifest or by adding files.
The basic command for adding files has this format:

jar uf jar-file input-file(s)

In this command:

• The u option indicates that you want to update an existing JAR file.
• The f option indicates that the JAR file to update is specified on the command line.
• jar-file is the existing JAR file that's to be updated.
• input-file(s) is a space-delimited list of one or more files that you want to add to the Jar file.

Any files already in the archive having the same pathname as a file being added will be overwritten.
When creating a new JAR file, you can optionally use the -C option to indicate a change of directory. For more information, see the Creating a JAR File section.

Examples

Recall that TicTacToe.jar has these contents:

META-INF/MANIFEST.MF
TicTacToe.class
TicTacToe.class
TicTacToe.java
audio/
audio/beep.au
audio/ding.au
audio/return.au
audio/yahoo1.au
audio/yahoo2.au
example1.html
images/
images/cross.gif
images/not.gif

Suppose that you want to add the file images/new.gif to the JAR file. You could accomplish that by issuing this command from the parent directory of the images directory:

jar uf TicTacToe.jar images/new.gif

The revised JAR file would have this table of contents:

META-INF/MANIFEST.MF
TicTacToe.class
TicTacToe.class
TicTacToe.java
audio/
audio/beep.au
audio/ding.au
audio/return.au
audio/yahoo1.au
audio/yahoo2.au
example1.html
images/
images/cross.gif
images/not.gif
images/new.gif

You can use the -C option to "change directories" during execution of the command. For example:

jar uf TicTacToe.jar -C images new.gif

This command would change to the images directory before adding new.gif to the JAR file. The images directory would not be included in the pathname of new.gif when it's added to the archive, resulting in a table of contents that looks like this:

META-INF/MANIFEST.MF
META-INF/MANIFEST.MF
TicTacToe.class
TicTacToe.class
TicTacToe.java
audio/
audio/beep.au
audio/ding.au
audio/return.au
audio/yahoo1.au
audio/yahoo2.au
example1.html
images/
images/cross.gif
images/not.gif
new.gif

Seven Questions Employees Should Ask Before Joining a Startup

While most people want to learn related to founders/entrepreneurs and venture capitalists about startups, most people involved in startup endeavors fall under neither of those categories. They’re employees.

There are many benefits associated with joining a startup as an employee at any level (energized work atmosphere, little bureaucracy, upside), but there are many significant risks coupled with them as well. Of course, a prospective employee should ask numerous questions of both his/her role and the company before joining any firm, but there is a set of questions specific to joining a startup that people should pose. I’ve tried to outline what I think are some of the most important questions below. Keep in mind that this is by no means an exhaustive list, merely a suggested seven to get a discussion going. I encourage everyone to suggest additional questions in the comments section below.

Q) If you are receiving employee options, what is the number of fully-diluted outstanding shares?
Typically, option grants are a key component of compensation in a start-up and are often promoted as such. But the details surrounding stock options are often complex and confusing for non financially-oriented individuals. It is best for employees to understand as much as possible about their option grants (this subject could be the topic for an entire series), but the first place to start is to ask how many outstanding shares there are. From that point, one can calculate the percentage of the company an employee will own and a better gauge of the magnitude of this compensation component. It surprises me how many startup employees I know who are excited to have received a grant of x number of options, but never bothered to ask what relative percentage of the company that translates into.

Q) Has there ever been a down round, a flat round, or a CEO change?
Any of these three events are an indicator that the startup has faced some difficulties in the past and may not be on track moving forward. If one of them has occurred, prospective employees should seek out as much information as they can the context of the situation. After all, there are exceptions to blind the assumption that these are a black mark (e.g. a founding CEO stepping aside to make room for professional management could be an indicator of successful growth). However, if any of these issues have arisen, it is a signal to dig deeper into the health of the business.

Q) What is the burn rate and how much cash is in the bank now?
Even if a start-up is successfully executing, it could still face a cash crunch if it is not yet profitable. Employees should ask to find out how much longer the company will ride without the infusion of another round capital. While the actual answer to this question won’t necessarily provide a definitive answer about the ability for the company to access both cash and capital, it will open up a discussion about it.

Q) What is the plan for exit strategy and its timeframe?
The answer to this question is a soft one with many factors, and can always change depending on circumstances. However, it is best to find out management’s view of a possible exit strategy. Is the company pieced together for a quick flip, building for multi-year significant value creation, or plan on holding for the long term as an eventual cash cow (for founder/investors)? These expectations will affect not only how long employees may be working for the company as it exists today, but more importantly, the resulting surrounding corporate culture.

Q) Could you meet the CEO, the founder(s), and those on the management team?
Start-ups are all about the people involved. And there are a small number of people who are largely going to affect the organization. Even if an entry-level employee is going to work in engineering, I think it makes sense for him/her to meet the VP Sales; likewise, a marketing manager should meet the CTO. Yet it might not happen unless the prospective employee requests it. The handful at the top are going to have a profound affect on the future of the company as a whole and the position (regardless of function), and therefore it is best to meet as many people possible in the company possible before joining.

Q) Are there plans in the next six months to hire anyone along the chain-in-command between your position and the CEO?
Start-ups often have key vacant positions open as the companies expand and grow quickly. I recommend explicitly asking if there is an anticipated change in the reporting structure in the foreseeable future, as any modifications or additions (even those a few rungs up in the ladder) could significantly affect employees’ roles and responsibilities.

Q) How many employees did/does/will the company have six month ago, now, six months from now, a year from now?
Employee count is a strong (but not a perfect) proxy for management’s and investors’ outlook on the business. Start-ups hire ahead of growth (or at least predicted growth), which translate into a viable company, a healthy work environment, and future internal opportunities. Financial figures and projections are helpful indicators, certainly, but are often a distortion of the full picture (especially early on in a company’s cycle). The growth in employee count (or lack thereof) directly signals how much work needs to be accomplished how rosy the expectations are.

Weblogic Errors & Resolutions

1. Change Development Mode to Production mode in Weblogic: Some of you have requested how to change Weblogic start up mode from DEV to production or vice versa. Actually it is very simple. One way to change it is, by simply editing setDomainEnv.cmd which resides in $root_domain/bin folder.
1. Look for the line that sets the PRODUCTION_MODE script variable: set PRODUCTION_MODE, set false to the value of the PRODUCTION_MODE variable to ensure the server starts in development mode,set true for starting in prod mode. [set PRODUCTION_MODE=false]
2. Save your changes and exit the text editor.
2. Authentication Denied - Boot identity not valid: "<11-May-2007 20:00:57 UTC> <Critical> <Security> <BEA-090402> <Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.>" Follow the following steps:
1. Remove the boot.properties file completely from the managed server directory.
2. Remove the ManagedServerDir/data/ldap directory completely.
3. Always keep backup of files before removing it.
4. Now try to start the server from the command prompt and provide the username/password used to login to the Admin Console.
3. Recover SerializedSystemIni.Dat When It Gets Corrupted: Follow following steps in order to recover SerializedSystemIni.Dat file:
1. Go to DOMAIN_HOME/config
2. Open the config.xml file and remove any encrypted sections from the <credential-encrypted> attributes. Replace its content with “”, Save the file.
3. Go to DOMAIN_HOME/servers/AdminServer/security
4. Remove the boot.properties file if exists.
5. Go to DOMAIN_HOME/security
6. Remove SerializedSystemInit.dat
7. Go to DOMAIN_HOME/ and Rename the fileRealm.properties to fileRealm.properties.src, then open fileRealm.properties.src and change all the hashed passwords (encrypted passwords) to clear text passwords.
1. For example:  user.system=0xaxyzb45e6f6c4eefdd1f14495ff739b5536904c to user.system=password
2. Ensure to use the same password that was set to the domain.
3. Save the file.
8. Open a terminal and go to DOMAIN_HOME/bin
1. Execute source ./setDomainEnv.sh
2. Then execute (in the same open terminal) the following script to re-generate 'SerializedSystemIni.dat' and 'fileRealm.properties' file:
1. java weblogic.security.acl.internal.FileRealm fileRealm.properties SerializedSystemIni.dat
9. Now open startWeblogic.sh located at DOMAIN_HOME/bin and add this line in JAVA_OPTIONS=-Dweblogic.system.StoreBootIdentity=true, This will create boot.properties file. Save the script & Start Weblogic with startWeblogic.sh or startWeblogic.cmd and give enter the user and password when asked.
4.  Exception Snippet: <Dec 31, 2013 2:06:30 PM UTC> <Error> <JTA> <BEA-114089> <User [<anonymous>] is not authorized to invoke ackPrepare on a Coordinator.>
   <Dec 31, 2013 2:06:30 PM UTC> <Error> <JTA> <BEA-110495> <User [<anonymous>] is not authorized to invoke AckRollback on a Coordinator.>
1. Bea Cause and Action are not very useful, i played with 'Cross-domain security' and 'interoperability mode' and reproduce this problem and come across, finally i came to conclusion that these errors only happened when i had a cross domain security enabled (with identical credentials on both domain - or for some reason some one trying to setup global trust along with cross domain security ).
5. Inter-domain transaction: The domains and all participating resources must have unique names. That is one cannot have a JDBC data source , a server or a domain with the same name as an object in another domain or the domain itself.
6. Address Already in Use: 
1. ERR: transport error 202: bind failed: Address already in use
   Starting weblogic with Java version:
   ERROR: transport error 202: bind failed: Address already in use
   ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
   JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
   FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
1. Root Cause: Above error comes due to port usage problem, if during server stop/kill process if the port which weblogic server is using not reclaimed by OS and user again issued the command to start the Weblogic server instance then servers try to bind the same port while another process is already running on that port and Weblogic server fails to start.
2. Solution: This error mostly comes when user forcefully kill the server, so before restart please check all the ports status which weblogic using e.g. http port , ALSB_DEBUG_PORT and DEBUG_PORT  by using this command -
   netstat –an | grep <port no> # to see which whether this port is active or not.
   e.g. netstat –an | grep 9001
   If you get the result from above queries then please wait and give some time to OS to reclaim this port, most of scenarios Port will be get free after some time and you can restart the servers again.
   In case above port is not getting released it simply means there is some process holding this Port, that process could be existing Weblogic PID or some demon thread, engage your Unix Administrator to find out that process and kill the process.
   Also we can bounce the whole server to release this port.
   In case of if this problem is coming for ALSB_DEBUG_PORT and DEBUG_PORT , then you can change this port number as well since these port are internal to Weblogic and does not used by any external system communication.
7. Exception while starting Weblogic Server: Err: Error occurred during initialization of VM
   Could not reserve enough space for object heap
1. Root Cause: You would get better help for this on WebLogic Server or a Java forum. The above problem is a fairly typical JVM and operating system interop issue. On startup JVM tries to reserve a contiguous block of virtual memory for heap and permgen. If it is unable to do so, it fails to start. On 32-bit operating system, virtual memory address space is 4GB, but drivers and operating system processes can breakup the available space into smaller chunks such that Java is not able to allocate a contiguous block that it requires. Any number of things could of caused this to start happening all of a sudden. Anything from a Windows update to installing new hardware or software.
2. Several Possible Solutions:
1. Tries to reduce memory allocated to WLS java process. Move down small increments at a time until the server starts e.g. to 2gb/1gb/512m. Perhaps you can get your app to run with reduced memory.
2. Switch to a 64-bit operating system and a 64-bit JVM. Note that you don't need more than 4GB of actual ram to get a benefit from a 64-bit environment in this case. It is the size of the virtual memory address space that counts. You will need to seek advice on WebLogic Server forum regarding configuring WLS to run with a 64-bit JVM.
3. Switch to running WLS using Jrockit. I do not believe Jrockit has the contiguous memory requirement.
4. Do some low-level debugging to identify which drivers or dlls are loaded where in memory and uninstall offenders or attempt to move them. You can find information on this via Google, but I don't really recommend doing this unless you enjoy low-level debugging and have some experience with it.
5. If above error is coming due to less memory allocated while your JVM need more then try increasing the memory as well in incremental mannerk solution could be increase the Min and Max size of JVM if your server have enough Memory , as a best practise Min and Max size always should be equal so that during Initiliation itself JVM will reserve that much memory.
6. In setDomainEnv.sh file find out this properties ‘EXTRA_JAVA_PROPERTIES’ and add this lines “-Xms3072m -Xmx3072m” or “-Xms3g –Xmx3g” Or in Weblogic Admin server console, click on server, go to “server start” tab page and specify JVM parameter “-Xms3072m -Xmx3072m” or “-Xms3g –Xmx3g”
   Verify the .out file whether changes is getting effected or not.
8. Err: Could not obtain an exclusive lock to the embedded LDAP data files directory
   <31/05/2012 4:32:08 PM EST> <Error> <EmbeddedLDAP> <BEA-171519> <Could not obtain an exclusive lock to the embedded LDAP data files directory: /hta/home/fusion/osb_home/osb_install1/user_projects/domains/vhaosb-dev2/servers/AdminServer/data/ldap/ldapfiles because another WebLogic Server is already using this directory. Ensure that the first WebLogic Server is completely shutdown and restart the server.>
   <31/05/2012 4:32:16 PM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
   <31/05/2012 4:32:16 PM EST> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
   <31/05/2012 4:32:16 PM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>
1. Root Cause: Some time even after proper shutdown or forceful shutdown .lok file does not get removed automatically and when users try to restart the server again and since file is already present it server fails to start the servers.
2. Solutions: Navigate to Idapfiles location under server and delete the “EmbeddedLDAP.lok” file from there, location would be e.g. /hta/home/fusion/osb_home/osb_install1/user_projects/domains/vhaosb-dev2/servers/AdminServer/data/ldap/ldapfiles and restart the Weblogic Server.
9. Err: The persistent store "_WLS_AdminServer" could not be deployed: <01/06/2012 10:56:47 AM EST> <Error> <Store> <BEA-280061> <The persistent store "_WLS_AdminServer" could not be deployed: weblogic.store.PersistentStoreException: [Store:280105]The persistent file store "_WLS_AdminServer" cannot open file _WLS_ADMINSERVER000000.DAT.
   weblogic.store.PersistentStoreException: [Store:280105]The persistent file store "_WLS_AdminServer" cannot open file _WLS_ADMINSERVER000000.DAT.
                   at weblogic.store.io.file.Heap.open(Heap.java:312)
                   at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:104)
                   at weblogic.store.internal.PersistentStoreImpl.recoverStoreConnections(PersistentStoreImpl.java:413)
                   at weblogic.store.internal.PersistentStoreImpl.open(PersistentStoreImpl.java:404)
                   at weblogic.store.admin.AdminHandler.activate(AdminHandler.java:126)
                   Truncated. see log file for complete stacktrace
   <01/06/2012 10:56:47 AM EST> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:
1. Root Cause: Above error comes mostly when weblogic does not able to read the file store .DAT file. This file weblogic uses for its internal working. There are 7 weblogic sub systems which write information in this file e.g. Diagnostic Service, JMS Messages, JTA Transaction Log (TLOG), Web Services, EJB Timer Services, Store-and-Forward (SAF) Service Agents and Path Service. Also this file could be corrupted as well during forceful shutdown when users use kill -9 command, or reason can be anything else as well.
2. Solution: 
1. cd $DomainHome/servers/AdminServer/data/store
2. find . –name  *.DAT
3. Verify the file name in your result and error message should be same.
4. Rename this file and move from this directory to some other directory.
5. find "EmbeddedLDAP.lok" and "AdminServer.lok" as well and remove the same.
6. check the port using netstat –an | grep <Weblogic server port>, there should not be any open connection to this port.
7. Start your weblogic server either via weblogic script or node manner.
1. Note: .DAT file is very important file, and contains business data as well in Production system. Please take a backup of this file before doing any operation on it, so that later this file can be analysed to complete those transaction.
10. ERR: The loading of OPSS java security policy provider failed due to exception: <Jun 5, 2012 1:37:53 PM EST> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag -Djava.security.debug=jpspolicy to get more information. Error message: JPS-02592: Failed to push ldap config data to libOvd for service instance "idstore.ldap" in JPS context "default", cause: org.xml.sax.SAXException: Error Parsing at line #1: 1.
    org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; <Line 1, Column 1>: XML-20108: (Fatal Error) Start of root element expected.
1. Root Cause: I need to find out exact root cause of this problem. As of now I am not quoting any details for why this error came but the solution which I have followed I am specifying here -
2. Solution: 
1. delete “tmp” folder from the location $Domain\servers/AdminServer.
2. find out all the .lok file and .DAT file and delete it.
   Find <location up to $Domain/servers/AdminServer> –name *.lok
   Find <location up to $Domain/servers/AdminServer> -name *.DAT
   Use the “rm” command to delete the files which comes as part of above find result.
3. Restart the Weblogic server. 
11. ERR: EmbeddedLDAP  java.lang.ArrayIndexOutOfBoundsException
    During Admin server restart we were getting below error continuously and Admin server was not coming up-
    ####<Nov 5, 2012 4:47:05 AM EST> <Critical> <EmbeddedLDAP> <vans075007> <AdminServer> <VDE Replication Thread> <<anonymous>> <> <> <1352051225634> <BEA-000000> <java.lang.ArrayIndexOutOfBoundsException: 0
1. Root Cause: This Error comes when the changelog.data  and changelog.index file get corrupted located in servers/Adminserver/data/ldap/ldapfiles .
   Below are list of scenarios during when these file can get corrupted.
   While the admin server was writing an LDAP entry to the changelog, it was interrupted by a forced shutdown, which made the changelog partially updated.
   When the admin server rebooted, it attempted to process the changelog (i.e., send the entries to the managed servers), but encountered the partially updated changelog.
   The partial update was an entry that had been assigned a change number, but there was no data for the entry. When the change log writer is interrupted between the index update and the data update and this update is in a synchronized method.
2. Solution: This Error comes when the changelog.data  and changelog.index file get corrupted located in servers/Adminserver/data/ldap/ldapfiles .
   Please take a backup of existing “ldap” folder deleted these two files, and restart the Admin servers. Both files will be created again and server will start successfully.
   The changelog.data file is used in WebLogic Server (WLS) to store LDAP information regarding users, groups, roles and policies. The EmbeddedLDAP server has an index file and a data file. Each entry in the data file is pointed to by a index file entry; the index file entry is dictated by an integer that identified the entry.
   For more details about issue and solution please refer the Oracle Note: DOC ID: 1325978.1, Following is list of general action which we can perfom in Test enviornment to fix the server startup problem:
1. Try to delete all the .lok file
2. Try to delete .DAT file insider $Domain/servers/AdminSever/step.
3. Take a backup of "tmp" folder inside servers folder and delete “tmp” folder
4. Take a backup of "data" foler inside servers folder and delete “data” folder
5. Change the port number if some port is already in use.
12. To be continued ...

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.