Intelij Idea and the Subversion integration: forbid SVN to lock the files in a repository

If you enable the Subversion in the Intelij Idea, you can face the problem that the every time you edit the file, it became locked in the repository. To avoid it, you can tel the Intelij to lock the file using file system.

To do, according to the http://www.jetbrains.com/idea/webhelp/changing-read-only-status-of-files.html

You can choose the option lock the file "Using file system", and tick the checkbox: "Do not show this dialog in future".

After it the Intelij Idea won't lock any files in a repository

Get the path to the executed sh with $(dirname $0)

Lets imagine that you have an A.sh file, that uses some relatives path from this file. Something like: "../.."
And some times you run A.sh file directly, ans sometimes you call it from another B.sh. And when you cal it from B.sh all relatives paths in A.sh could not work any more.

To make the A.sh properly works in both cases you can use something like:

 $(dirname $0)/../..  

The $0 command should return the path from the A.sh file to the B.sh concatenated with /B.sh (file name of the .sh that i called from an other .sh file)

And dirname simply truncates everything after the last slash with the last slack itself. I our case it will truncate /B.sh. If B.sh will be called directly, $0 will return ./ and dirname will do nothing, so everything will work in this case, too.

Java initialization order

I was interested in what order java initialize objects in the class and its duper class. So, I wrote small program to get it:

 class Super {  
   static {  
     System.out.println("The first Super static init block");  
   }  
   static StaticSuperField staticSuperField = new StaticSuperField();  
   SuperField superField = new SuperField();  
   static {  
     System.out.println("The second Super static init block");  
   }  
   Super() {  
     System.out.println("The Super constructor");  
   }  
   {  
     System.out.println("The Super non-static init block");  
   }  
 }  
 public class Sub extends Super {  
   {  
     System.out.println("The Sub non-static init block");  
   }  
   static {  
     System.out.println("The first Sub static init block");  
   }  
   static StaticSubField staticSubField = new StaticSubField();  
   private SubField subField = new SubField();  
   static {  
     System.out.println("The second Sub static init block");  
   }  
   Sub() {  
     System.out.println("The Sub constructor");  
   }  
   public static void main(String[] args) {  
     new Sub();  
   }  
 }  
 class StaticSubField {  
   public StaticSubField() {  
     System.out.println("The static sub field");  
   }  
 }  
 class SubField {  
   public SubField() {  
     System.out.println("The sub field");  
   }  
 }  
 class StaticSuperField {  
   StaticSuperField() {  
     System.out.println("The static super field");  
   }  
 }  
 class SuperField {  
   SuperField() {  
     System.out.println("The super field");  
   }  
 }  

And got the output:

The first Super static init block
The static super field
The second Super static init block
The first Sub static init block
The static sub field
The second Sub static init block
The super field
The Super non-static init block
The Super constructor
The Sub non-static init block
The sub field
The Sub constructor

So, clear to see that the first class that is loaded to the JVM will be the super class of need Sub.

Also, you can see static members (not important which blocks or field) runs in the order that they appears in the code.

Obvious that the all fields initialized before a constructor finishes, and after the Super constructor runs.

Finally the initialization order of a class is:

1. Static members (in the order they appeared in a class, not important if it is block or field).
2. Non-static fields are given their default values
3. Than the constructor starts and calls super();
4. After super() is finished, non-static members are initialized, and here the same rule as for statics members(in the order they appeared in a class).
5. And the last step, a constructor finishes.

Shell script that call stored procedure by the sqlplus

If you want to write the .sh file that will call sqplus that should execute the sql query, you can try something like this:

 sqlplus <db_username>/<db_password>@//<db_host>:<db_port>/<db sid> <<EOF  
 exec <function_package_name>.<function_name>;  
 exit;  

This example shoul call stored procedure. You can change it to execute any sql query.

Webshere: creating the profile using gradle

This gradle script will create the profile that will be administrative secure with the usename "admin" and the password "admin"

More about passed parameters and the parameter that you could additionalyy pass, you can read here:
http://pic.dhe.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.ops.doc%2Finfo%2Finstall%2Frinstallprofile_silent.html

The webshere ports will be starting from the 13000.

To delete profile, you can use the script simmilar like in the http://b1102.blogspot.de/2014/07/gradle-escaping-spaces-in-arguments-for.html

 import org.apache.tools.ant.taskdefs.condition.Os  
 task createProfile(type: Exec) {  
     description = 'Create WebSphere Application Server profile.'  
     def isWindows = Os.isFamily(Os.FAMILY_WINDOWS)  
     def cmdExtension = isWindows ? 'bat' : 'sh'  
     def manageProfilesFileName = File.separator + "manageprofiles." + cmdExtension  
     //Path to your webshere installation  
     def wasHome = 'C:/IBM/WebSphere/AppServer'  
     def templatePath = wasHome + File.separator + "profileTemplates" + File.separator + "default"  
     //Path to the wsadmin.bat or wsadmin.sh  
     def wsadminLocation = wasHome + File.separator + "bin"  
     def manageProfilesFile = new File(wsadminLocation, manageProfilesFileName)  
     executable = manageProfilesFile  
     def argsList = ["-create", "-profileName", "Profile1", "-templatePath", templatePath,  
                     "-nodeName", "AppSrv01", "-cellName", "AppSrv01Node1",  
                     "-serverName", "AppSrv01Node1Serve1", "-enableAdminSecurity", "true",  
                     "-startingPort", "13000", "-adminUserName", "admin",  
                     "-adminPassword", "admin"]  
     //defines will this profile will be the default one or not  
     def isDefault = true  
     if (isDefault) {  
         args.add("-isDefault")  
     }  
     if (isWindows) {  
         argsList.add("-winserviceCheck")  
         argsList.add("true")  
         argsList.add("-winserviceUserName")  
         argsList.add("Administrator")  
         argsList.add("-winserviceStartupType")  
         argsList.add("automatic")  
     } else {  
         argsList.add("-enableService")  
         argsList.add("true")  
         argsList.add("-serviceUserName")  
         //any desired service user name  
         argsList.add("root")  
     }  
     args = argsList  
 }  

Gradle: escaping spaces in arguments for the task “type:Exec”

Gradle have problems when try to pass many arguments to its task with the type of "Exec".
The more accurate the problem is decribed here: http://stackoverflow.com/questions/20613244/gradle-execute-task-typeexec-with-many-arguments-with-spaces

The solution is simple: path the parameters as arguments list, like this:

 task callProfileDelete(type: Exec) {
      description = 'Delete profile with wsadmin.'
      executable = manageProfilesFile
      args = ["-delete", "-profileName", "My profile name"]
 }

In this case you will path always the correct number of arguments and the "space" will escaped nicely.