Maven jax-ws plugin usage

This post shows an example of jax-ws maven plug-in usage. This maven plug-in can be found in two repositories

1. org.codehaus.mojo
2. org.jvnet.jax-ws-commons

First repository contains old versions of this plug-in. ( available upto versions 1.12 ). Second one has the Latest version (2.3) and it can be found in http://jax-ws-commons.java.net/jaxws-maven-plugin/. To use latest version, replace groupID and version fields with following .

 <groupid>org.jvnet.jax-ws-commons</groupid>

 <artifactid>jaxws-maven-plugin</artifactid>

 <version>2.3</version>

Working with SOAP Headers in BPEL - WSO2 BPS / Apache ODE

Most of the web services use soap headers to pass various kinds of information and it is required to manipulate those headers within a BPEL process when we are creating a complex business logic. Sometimes we have to deal with soap headers which aren't declared in the WSDL abstract message. These kind of headers are called Dynamic headers and both Apache ODE and WSO2 BPS can handle these type of soap headers.

For more information about header handling in Apache ODE, follow this article.

This post will show you how to handle soap headers, covering following scenarios,

1. Reading a soap header in request message.
2. Create a new soap header in a variable and assign a value to it.
3. Copying soap header from one variable to another.  

Sample BPEL Process

To demonstrate above scenarios let's consider this simple BPEL process. These are process's default request and response messages.


1. Reading SOAP Header in Request Message.

Let's read "echo" header from the input message and set its value into the process output message (to result element). To do this, add another copy into the Assign activity like this. Note that we are using "header" attribute to refer a soap header. (Resultant process's response is shown in response.xml)


2. Create a new soap Header in a variable and assign a value to it

Let's add new soap header called "echo2" in the output variable and assign request message text (input) value as new header value. First copy will create the echo2 header and second copy will do the value assigning. (Resultant response is shown in response.xml)

3. Copying soap header from one variable to another.  

Let's copy request message's echo header to output message. In the Assign activity define a copy as follow. (Resultant response is shown in response.xml)

Mocking an Asynchronous Web Service using SoapUI.

This is an example scenario.

Echo service is an asynchronous web service and this is the service which we are going to mock using SoapUI. Clients send requests to the echoService using ws-Addressing. Echo service uses ws-addressing headers to identify client's callback information and sends back echo-Response to client's callback services.

Tools used:

• SoapUI 4.5.1
• WSO2 Developer Studio 3.X ( to create wsdls files)

Step 1 : Obtain or Create wsdls files of the services which you are going to mock and client callback service.


Here I am using EchoService.wsdl file as my service's wsdl and ClientCBService.wsdl as client's callback service wsdl.

Step 2 : create a new SoapUI project using service and client WSDLs.

• Open SoapUI.
• Then goto File -> new SoapUI project or use shortcut key Ctrl + N
• Give the your service wsdl path in initial wsdl/wadl filed and give an appropriate project name. ( Let's say EchoService ) and Click OK

Now Let's add client's wsdl into the same project.

• right click on your SoapUI project and select "Add wsdl"

• In "Add WSDL" window select your client wsdl and Click OK

( Note: Create Sample Requests for both server and client's callback operations if they were not created by default )



 Step 3 : Generate Mock service for EchoService

• Right click on EchoService and select Generate MockService

•   In Next windows click OK to create mock service with default values.

• Now we have created the mock service. In Mock service window, click configure icon ( the most right icon) to set host name and port.

• Give host name as localhost and give port which you prefer.

Step 4: Create a TestCase to invoke Client's callback service with echoService response. 

• Right click on the client wsdl project and select Generate TestSuite.

•  In next windows Click Ok to reate test suite with default values.

 

•  Now You have create the TestSuite. Open the test-step which was created by default. Set echoString and messageID parameters in the request message. ( you can set parameter using ${parameter_name} )

•  We will extract and set values to the above parameters in next step.

Step 5 : Write a groovy script to handle asynchronous behavior of the service.

•  Double click on echo Operation in Mock-Service

•   In opened Window select Dispatch type as Script.

•  Then enter following code as our dispatch logic. It extract values from incoming request and parse to the testcase using a map. Also it sets testcase's end point address to the value that came with ReplyTo header.

Note: I wrote above script by modifying an answer in stackoverflow.com


Step 6 : Testing out Asynchronous Service

Now we have finished mocking our asynchronous service. But we need to have a callback service to get the response back.

• Let's create another soapUI project to mock the callback wsdl. Follow above steps to create a mock service for client callback. For your reference I have added only few screenshots of most important steps. Note that I am using port as 8087 and host as localhost.

• Start client Callback service by clicking green arrow of the mock service.

•  Start our asynchronous echo (mock) service.

• Now we are ready send a request to our mock service. Open request in EchoServiceSOAP and add mockservice endpoint to it.

•  Click WS-A tab and enable ws-addressing. Then set "Action", "To", "ReplyTo", and "MessageID" fields in the request message as follow.

•  Now we are ready to invoke our service. Click submit button in request window to send the request to mock service.

• It returns an empty response. But if you check your callback service, you can see that actual echo response was sent to it.

• You can view incoming request messages in both mock-services windows. Open both echoService request and echoReult message and Compare them for echoed string and ws-a messageID. ( see bellow screenshot.)

Links to Files:

• EchoService.wsdl 
• ClientCBService.wsdl 
• EchoService-soapui-project.xml
• ClientCBService-soapui-project.xml

Invoking Secured ESB Proxy Service Using SOAP UI

In this post, I am showing how you can invoked a secured proxy service, using SOAP UI tool.

Here I am using WSO2 ESB 4.6 and SOAP UI 4.5.1for this example.

Step 1: Create a proxy service 

Let's create a ESB proxy service first. Here I have created a proxy service to invoke echo service that comes with WSO2 ESB.


First let's try to invoke our proxy service without security. Here I am using tryIt tool. Click "Try this service" link in the EchoProxy row in the Deployed service. Use following sample request to invoke the service.

Request and Response of the EchoProxy

Step 2: Creating SOAP UI Project and Testing service.

• Open SOAP UI tool and Create an new soapUI Project. ( File -> New soapUI project )
• In the new soapUI project wizard, give the our EchoProxy service's wsdl url. (ex: http://localhost:8280/services/EchoProxy?wsdl ) 
• Give the project name as "EchoProxy". Fill other fields as necessary.
• Then Click Ok.
• Then try to invoke our proxy service using soapUI as well.

 

Step 3: Securing the proxy service

Let's secure our proxy service now.

• Go to service list (see 1 in Figure 1)
• In Service list view, click on unsecured link (see 2 in Figure 1) in the EchoProxy row to secure the proxy.

Figure 1

• In next Window, select "yes" to enable security for EchoProxy  ( Figure 2)

Figure 2

In this example, I am going to secure proxy service using security scenario 5 - "Sign and Encrypt - X509 Authentication"

• So select security scenario 5 under Advanced Scenarios ( Figure 3 ) and click next.

Figure 3

• For simplicity of this post, I am going to use wso2carbon.jks as Trusted Key Stores. So in next window ( Figure 4) Select wso2carbon.jks as Trusted Key Stores and click Finish. 

Figure 4

• Now we have secured proxy our service.

Figure 5

Note: If you try to invoke our proxy service now using tryit or soapUI tool, it will fails. In next step let's try to invoke it by adding Sign and Encrypt - X509 Authentication to the soapUI request.

Step 4: Adding Sign and Encrypt - X509 Authentication to soapUI request.

Step 4.1 - Setting up ws-security configuration to soapUI project.

• Right Click on your soapUI project (EchoProxy) and select "Show Project view" 
• In the opened sub window, click "ws-security configuration" tab.
• Now let's add a KeyStore first. For Simplicity I am adding wso2carbon.jks here again. You can find it from $ESB_HOME/repository/resources/security/ . But you can use your own valid keystore here.

Step 4.2 - Adding KeyStore

• Go to the keystores tab ( see figure 6)
• Add a keystore by clicking the button which is shown using arrow 1 in figure 6.
• Select key store file. (ex: $ESB_HOME/repository/resources/security/wso2carbon.jks) 
• It asks the password of the keystore. Give it. ( for wso2carbon.jks password is wso2carbon )
• Then fill the Default Alias and Alias password fields. I am using wso2carbon for both fields. 

Figure 6

Step 4.3 - Setting up Out going Security Configuration.

• Go to outgoing ws-security configuration tab.
• Click button 1 ( Figure 7 ) to add outgoing security configuration. 
• Give an unique name for the configuration. let's say it as EchoProxy-soap11SecuredRequest
• Then fill the default Alias/Default Password fields. Use wso2carbon for both fields.
• Then tick the must understand check box button.

Figure 7

• Now Let's add wss entries. Click button 1 ( Figure 8) to add new wss entry.
• First add Timestamp entry.
• In the option window, fill the "time to live" field (ex: 300000)

Figure 8

• Then let's add signature entry similar to timestamp.
• Fill the options fields as given in figure 9.  
• Keystore is wso2carbon.jks;
• both alias and password is wso2carbon;
• Key Identifier type is X509;
• tick the use single certificate check box;
• Leave other fields as default;
• Then add a new part; which describes what we are going to sign. Since we are signing body of the soap11 request, let's add new part like this.
• ID=Body
• Name=Body
• Namespace=http://schemas.xmlsoap.org/soap/envelope/
• Encode=content

Figure 9

• Since our proxy service is secured using sign and encryption, we need to add encryption as well. So add encryption entry similar to Timestamp and signature fields.
• Fill the option fields as given in figure 10. 
• Keystore is wso2carbon.jks;
• both alias and password is wso2carbon;
• Key Identifier type is X509;
• tick the create encryption key check box;
• Leave other fields as default;
• Then add a new part; which describes what we are going to encrypt. Since we are encrypting  body of the soap11 request, let's add new part like this.
• ID=Body
• Name=Body
• Namespace=http://schemas.xmlsoap.org/soap/envelope/
• Encode=content

Figure 10

Now we are done with configuring out going message.

[Important] Please note that order of the ws entries matters when we are invoking the secured service. So always add those three one after the other. As an exercise try to change order of timestamp, signature and encryption and try to invoke the service.

Step 4.4 - Setting up Incoming Security Configuration.

• Go to incoming ws-security configuration tab.
• Similar to outgoing ws-security configuration first add incoming security configuration profile. Name it as EchoProxy-securedResponse
• Fill the other fields as showing in figure 11.
• Decrypt Keystore=wso2carbon.jks
• Signature Keystore=wso2carbon.jks
• password=wso2carbon

Figure 11

 Step 5 - Invoking secured Proxy service.

 

• Open soap11 request. ( If you have already opened it, you may have to close and re-open it, to apply project changes which you did in step 4)
• Click on button aut ( arrow 2 in Figure 12 ). It contains authentication related details.
• Select outgoing wss that we created in step 4 from arrow 3.
• Select incoming wss that we created in step 5 from arrow 4.
• Then Invoke the request 1 by clicking green play arrow.

Figure 12

•  you can view decrypted response from response window.  it is Done :)

[Important] Troubleshooting.

• If you are running your system on a fresh JVM, you may face "Illegal key size or default parameters" [1] or similar problems since we are using encryption algorithms in this sample. To fix this you have to patch the JVM by applying "the Java Cryptography Extension (JCE), Unlimited Strength Jurisdiction Policy".
• You can download it from http://www.oracle.com/technetwork/java/javase/downloads/

 

[1]

.....

Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size or default parameters
Original Exception was java.security.InvalidKeyException: Illegal key size or default parameters
    at org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1140)
    at org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1081)
    at org.apache.xml.security.encryption.XMLCipher.encryptElementContent(XMLCipher.java:855)
    at org.apache.xml.security.encryption.XMLCipher.doFinal(XMLCipher.java:985)
    at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:602)
    ... 24 more
Caused by: java.security.InvalidKeyException: Illegal key size or default parameters
    at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1011)
    at javax.crypto.Cipher.implInit(Cipher.java:786)
    at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
    at javax.crypto.Cipher.init(Cipher.java:1213)
    at javax.crypto.Cipher.init(Cipher.java:1153)
    at org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:1137)
    ... 28 more
 

HumanTask Event Listeners - WSO2 BPS

HumanTask engine comes with a humantask event generator. These task events are generated when a task goes trough a state transition. An event contains details about tasks and its state transition. So by writing a custom event listener to these events, a developer can easily enhance the HumanTask engine's functionalities.

What developer can do with a task event listener.

• Can do custom java code/ web service invocations.
• Can retrieve task information. 
• Developer free to implement their own logic depending on their requirement.

Sample Event Listener.

EventListener class should implement HumanTaskEventListener class and onEvent method. See following sample code.


How to deploy a custom listener to WSO2 BPS

1. Build a jar file of including your listener.
2. Copy it into /repository/components/lib. Where is the root directory of BPS server.
3. Uncomment TaskEventListeners in HumanTask configuration file (/repository/conf/humantask.xml) and give your Event Listener class name for ClassName.
eg:
Note: you can have multiple listener classes.

4. Start BPS.
5. Execute a task.

Escalating a human task with WSO2 BPS.

This Post describes, how to you can define a deadline within a human task. For this I am going to extend WSO2 BPS Claim Approval Task sample.

Prerequisite

• If you haven't tried the sample yet, try it first. So you get better idea about how human task works.
• Download WSO2 BPS 3.0.0 +
• an Text Editor.

Note: You can find more information about humantask deadlines and timeouts under section 4.9 in humatask specification. 

What I am going to do in this sample ...

In this sample, I have set deadline time duration for 5 minuets after task creation. The escalation is defined such a way that, if the claimed amount is less than 10000 and task not started within 5 minutes, then notify task's potential owners that current claim approval task is overdue.

Steps to Modify WSO2 BPS Claim Approval Task sample


1)  Setup BPS as mentioned in sample page.

Deploy BPEL package. Creates Roles and Users. But do not deploy humantask package ClaimsApprovalTask.zip since we are going to modify it in next steps.

2) Modify ClaimsApprovalTask.ht

Unzip ClaimsApprovalTask.zip and Add following deadline definition (i.e <htd:deadlines>) inside ApproveClaim task definition (i.e. <htd:task "ApproveClaim"> ) in ClaimsApprovalTask.ht


3) Replace ClaimsApprovalTaskService.wsdl

I did slight changes to wsdl file for this sample. So replace ClaimsApprovalTaskService.wsdl with this file.

4) Deploy Sample

Create new zip file including all files.(modified and unmodified) and deploy it in BPS.
( you can find modified sample from here )

5) Send a Sample Request.

After deployment, send a sample request (like given in sample page). You can see task is created under clerk login. Do not start the human task.

6) Wait 5 mins.

After 5 mins, deadline will be executed. As a result this, a notification is generated and sent to the clerk. Clerk can view notification under Home -> Human Tasks -> Notifications.   

Recovering your deleted files using - Foremost

I recently looking for data recovery tool to recover some files in my home folder. I was looking some recover tool for linux, and I found an interesting command line tool call Foremost.

Why is it so interesting ?

• light weight and easy to install. 
• Easy to use.
• Built in file filters for fast recovery. ( e.g: jpg, zip, rar etc.)

How to install foremost.

Go to terminal and  type.

$ sudo apt-get install foremost

Recovering deleted jpgs files in partition

1. First make an empty writable directory to save recover files in a partition other than that you are going to recover. ( let's say /recovery/data/ )
2. Then run foremost.  I am going to recover my home partition ( let's say /dev/sda5).

$ sudo foremost -t jpg -i /dev/sda5 -o /recovery/data


3. Finally set user permission to /recovery/data/ to view image. type

$ sudo chown YOUR_USER_NAME /recovery/data -R

Some important foremost command line arguments.

• -i  :- partition/image to recover
• -o :- location to store recovered files.
• -t  :- built in file filter options.  you can give multiple filters by separating using commas. (e.g: for jpg and pdf: -t jpg,pdf ) 
• -q :- quick mode.

 you can find more details about foremost in following locations.

1. https://help.ubuntu.com/community/DataRecovery#Foremost
2. http://linux.die.net/man/1/foremost

Writing an Assembler for CMinus using Antlr 3 and String Templates

Recently I wrote an assembler for DLX architecture using Antlr 3 as an assignment of the Advance architecture course module.
 

Target 

Main target of this assemble is to generate an optimized assembly code by filling delayed branch slots. It can take High level language code segment as a input. First it should generate unoptimized assembly code and then optimized it to fill delayed branch slots.


Why Antlr ?

Antlr supports String template which is a java template engine that can be used to generate any type of formated texts ( source codes, emails, etc). So using string template we can perform language transformation very easily. For example Java to C#, C++ etc. For more details look at Here .

you can find antlr 3 samples at github.  I modified the cminus sample available at github for this project. 


About project

I used Cminus as High level language and DLX (RISC architecture) as target platform. It used Antlr version 3.

This project is available at Google-code svn repository.


Limitations of the Code

• Fills only delayed branched that occurs after unconditional jump. ( j )
• Supports multiple for, while and doWhile loops in high level language.
• supports only addition.
• supports only == and < 
• do not support variable = variable + variable type assignments

and more.



Main Development Steps

1. Building Lexer and Parser using lexer rules.
• used Antlr IDE ( downloaded via antlr site) to generate lexer and parser.
2. Unoptimized code generation using string template.
3. Wrote optimizer  and Optimized code generation. 
4. Mavenized the project. 

Building Project and Run

you can build project using maven3. ($mvn clean install) .
Maven build will execute assembler after the build and generate optimized code for sample.txt. asem_optimized.txt and asem_unoptimized.txt will be created after the build.


Improvements to the Code base

I warmly welcome your suggestions and ideas to improve this assembler.

Tips - Some useful parameters for starting a WSO2 server

Before you start, first go to <CarbonHOME>/bin . Where <CarbonHOME> is the directory of the carbon server.


Start a carbon server with 1 port offset

(Useful when you need to start multiple servers (ESB, BPS, AS etc) at same time)

$ ./wso2server.sh -DportOffset=1



Start a Carbon server with remote-debug mode on port 5005


$ ./wso2server.sh debug 5005


 


Tips - Remote Debug with Maven 3 - Plug-in Debug

How to Debug a Maven Plug-in at Build time.

1) Open maven plug-in source code using your favorite IDE ( Eclipse, InterlliJ IDEA etc) and set break points in codes that you are going to debug.

2) Start build project using following command.

$ mvnDebug clean install 
 
3) maven starts to Listen on port 8000 till a remote debugger connects.

$ mvnDebug clean install
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
 
4) Start remote debug on port 8000 using your IDE. It will trigger the build process with remote debug.

Tips - Remote Debug with Maven 3 - Test-cases

How To Debug Test-cases with Maven at maven run time

1) Open your Project with your favorite IDE ( eclipse, intellij IDEA etc) and set break points that you are going to debug.

2) Build the project using following parameters

$mvn clean install -Dmaven.surefire.debug

3) It starts to build your project and it will stop at test cases.

[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ org.wso2.bps.integration.tests ---
[INFO] Compiling 41 source files to /data/source/branch/carbon410/platform/products/bps/3.0.2/modules/integration/org.wso2.bps.integration.tests/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ org.wso2.bps.integration.tests ---
[INFO] Surefire report directory: /data/source/branch/carbon410/platform/products/bps/3.0.2/modules/integration/org.wso2.bps.integration.tests/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Listening for transport dt_socket at address: 5005



4) Start remote debug on port 5005 using your IDE. It will trigger the build process with remote debug.


Source : http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html

Easy steps to enable Finger Print Reader on Linux Mint / Ubuntu

Here I am using Linux Mint 14 ( Mint is very similar OS to Ubuntu) on Lenovo ThinkPad machine.

Step 1 - is your Finger print reader detected by system...?

First check whether your figer print reader is recognized or not by the system. for this open terminal and run command.

$ lsusb

  

It shows information about USB buses in the system and the devices connected to them. Then look for your finger print reader device. (My finger print reader device, Upek is listed in device list.)

.. 

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 147e:2020 Upek 
Bus 001 Device 004: ID 04f2:b2eb Chicony Electronics Co., Ltd 
..

Step 2 -Installing fPrint

Use following commands to install fPrint.

$ sudo add-apt-repository ppa:fingerprint/fprint

$ sudo apt-get update

$ sudo apt-get install libpam-fprintd  

if Installation is success, the needed lines in common-auth should now be present. for that type following command in terminal

$ grep fprint /etc/pam.d/common-auth

you should observe similar output like this,

auth [success=2 default=ignore] pam_fprintd.so 

Final (Fun) Step - configure fPrint

Now run

$ fprintd-enroll

swipe your right index finger until process is completed.

Using device /net/reactivated/Fprint/Device/0
Enrolling right index finger.
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-completed

Now you should be able to authenticate (Login, Terminal,  Lock screen, and everywhere ) by swiping your right index finger.

see how it works on terminal authentication.

( Note: If finger print fails, then system automatically prompt you to enter password. )

Have fun...

Alternatives for fPrint:

I found another GUI client called Fingerprint GUI.( http://www.n-view.net/Appliance/fingerprint/ ) it has some advance features, compare to fPrint.

Reference: 

1. http://www.thinkwiki.org/wiki/How_to_enable_integrated_fingerprint_reader_with_fprint

Limit the scope of the SVN Checkout - Example

Assume We want to checkout WSO2 Carbon branch 4.0.0 source code from [1]. But our target branch source is located under following sub locations.  

1. https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0/
2. https://svn.wso2.org/repos/wso2/carbon/orbit/branches/4.0.0/
3. https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0/

To give you a better idea, above three svn locations are represented in tree view in the following diagram. 

carbon/
├── kernel
│   ├── branches
│   │   └── 4.0.0
│   ├── graduated
│   ├── tags
│   └── trunk
├── orbit
│   ├── branches
│   │   └── 4.0.0
│   ├── graduated
│   ├── tags
│   └── trunk
└── platform
    ├── branches
    │   └── 4.0.0
    ├── graduated
    ├── tags
    └── trunk

Possible Methods of SVN checkouts for our problem

We can either use following options.

1. checkout entire Carbon platform ( including trunk, branches, etc.) (  $svn co https://svn.wso2.org/repos/wso2/carbon  )
2. checkout each above svn code locations separately. ( $svn co https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0/  . Similarly other two locations.  )

But first method is too time consuming, because it checkout entire Carbon Platform. So second method seems to be a good choice, but is also have some (minor) negative points.

Since codes are not in same svn structure (as in the first method) in file system, maintaining can be a little bit hard. Also If you need to checkout another location ( for example let's say carbon/platform/trunk ), again you need to checkout it separately.

So it is better to have some mechanism to narrow down the svn scope when checkout the code. There are some reference articles in end of this post. Refer them to get more information about this technique. Let's see how we can do this.

[1] - https://svn.wso2.org/repos/wso2/carbon/

Limit the Scope of the SVN checkout

( Here I am using the subversion client which come with Ubuntu )

Let's try to checkout only following structure. 

carbon/
├── kernel
│   └── branches
│       └── 4.0.0
├── orbit
│   └── branches
│       └── 4.0.0
└── platform
    └── branches
        └── 4.0.0

Step 1 - Making svn structure up to 1 level depth. 

type following commands in terminal ( instructions are in bold letters.)

~/wso2 $ svn co https://svn.wso2.org/repos/wso2/carbon --depth immediates

A    carbon/orbit
A    carbon/kernel
A    carbon/platform
Checked out revision 160720.
~/wso2 $ 

this will create following svn structure on the file system.

carbon/
├── kernel
├── orbit
└── platform

Step 2 - Making path kernel/branches/4.0.0

type following commands in terminal ( instructions are in bold letters.)

~/wso2 $ cd carbon/kernel/

~/wso2/carbon/kernel $ svn up --set-depth empty branches

Updating 'branches':
A    branches
Updated to revision 160722. 

~/wso2/carbon/kernel $ cd branches/

~/wso2/carbon/kernel/branches $ svn up --set-depth empty 4.0.0

Updating '4.0.0':
A    4.0.0
Updated to revision 160722.
~/wso2/carbon/kernel/branches $

now we have created following svn structure.

carbon/
├── kernel
│   └── branches
│       └── 4.0.0
├── orbit
└── platform

 But still kernel/branches/4.0.0 doesn't contain any file. So let's update kernel/branches/4.0.0.

move to 4.0.0 directory using 

~/wso2/carbon/kernel/branches $ cd 4.0.0

Then type

~/wso2/carbon/kernel/branches/4.0.0 $ svn up --set-depth infinity

this will update all files located under https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0/.

Step 3 - Repeat step 2 for other two locations ( for orbit and platform ).

Advantages:

• All three locations are under some svn tree.
• Quick.
• Limits the scope and skips unnecessary locations. 
• Taking svn up at svn root directory ( in this example carbon ) will update only above three locations which we made using this examples. other will not update.
• Easy Maintenance.

Reference

1. http://svnbook.red-bean.com/en/1.7/svn.ref.svn.html
2. http://svnbook.red-bean.com/en/1.6/svn.advanced.sparsedirs.html

Ubuntu Tips - How Restore to Classic gnome desktop

1) Install gnome-session-fallback by typing following command.

sudo apt-get install gnome-session-fallback

2) Logout current session.

3) Select Ubuntu classic desktop from session chooser.

4) login :)