Solving the Error 127 from Make when cross compiling to raspberry pi

I was following the excellent tutorial from Alessio on cross compiling to raspberry pi from Windows 7. Then, I hit the the dreaded ‘Error 127’ from make. Now, after hours of searching I couldn’t find how to solve this. Then, Bryan has mentioned that you need to install the 32 bit cygwin version and that would work, and works it does.

If you already installed cygwin 64 bit version like me and wondering how to install it,here are some steps:

  1. download the 32 bit setup to a new directory(ex: C:\cygwin32) and run the setup. Make sure you make every path point to this new directory during the setup process.
  2. Now, copy the crosstools directory to this new directory. So, it will be at C:\cygwin32\opt\cross\x-tools\arm-unknown-linux-gnueabi
  3. Change all paths created in Eclipse in the ‘Path’ variable (and Windows Environment variables too, if you added cygwin there) to point to this new location
  4. Now, clean and build the project and it should compile for you!

Another error I ran across is this:

Could not determine GDB version after sending: C:\cygwin32\opt\cross\x-tools\arm-unknown-linux-gnueabi\bin\arm-unknown-linux-gnueabi-gdb.exe –version

If you ran across this you installed python 2.7 instead of 2.6. Re-run the cygwin setup and change the python version to 2.6.x.x and install this python version. Re-run your program and it should be working.

I wrote this so it helps someone else to save a ton of time. HTH.

Best Practices in the WSO2 Carbon Platform

 

This post discusses best practices when programming with the WSO2 Carbon platform, which is the base for all WSO2 products.

Here are the main points discussed in this post:

  1. Do not hardcode compile time, run time dependencies and re-use properties in the root pom.
  2. Use OSGI Declarative Services
  3. Do not copy paste code, re-use code through OSGI, Util methods, etc.
  4. Understand Multi tenancy and design for Multi Tenancy
  5. Write tests for your code

 

These points are discussed in detail below giving reasons and a HOWTO for each point. Hope you find the details useful as this is a long (and probably boring) read.

  1. Do not hardcode compile time, run time dependencies and re-use properties in the root pom.
Ex:
       <dependency>
            <groupId>org.json</groupId>
            <artifactId>json</artifactId>
            <version>1.0.0.wso2v1</version>
        </dependency>
Why do this?
This should be avoided as it threatens the stability of the build. If two versions of the same jar comes into a product, it can cause OSGI related errors, that can take some time to identify and fix.
How to avoid this?
Make sure the root pom (components/pom.xml or platform/pom.xml) has a dependency version defined, and use that.
Ex: in platform/pom.xml
<orbit.version.json>2.0.0.wso2v1</orbit.version.json>
If it is not defined, please define it in the root pom and use this version.
 
 
 
2. Use OSGI declarative services
Do not get service references in the activate method.
ServiceReference serviceReference = componentContext.getBundleContext().getServiceReference(Foo.class.getName());
        if(serviceReference != null){
            Foo = (Foo) componentContext.getBundleContext().getService(serviceReference);
        }
Why do this?
(Quoting, Pradeep here) This can lead to erroneous situations and you will have to check whether services are available in a while loop to make it work properly. And it becomes complicated when two or more service references.
Why bother to do all this when the DS framework handles all this for you.
How to avoid this?
Use a DS reference in your service component.
Ex:
 * @scr.reference name=”foo.comp”
 * interface=”org.wso2.carbon.component.Foo”
 * cardinality=”1..1″ policy=”dynamic” bind=”setFoo”  unbind=”unsetFoo”
protected void setFoo(Foo foo) {
// do whatever ex:
        manager.setFoo(foo);
}
protected void unsetFoo(Foo foo) {
// make sure lose the reference
        manager.setFoo(null);
}
3. Do not copy paste code, re-use code through OSGI, Util methods, etc.
 
If you need functionality provided by other components, don’t copy paste code. Find another way to re-use the code. If you need some common thing done most probably, there exists a util method to that, or an osgi method. If not add or create one.
Why do this?
 
It might take some effort and discipline but later on you (or someone else) will have to write less code. If changes happen to the original code, you will have to fix the copy pasted code as well (which is often missed).
How to do this?
 
i. Use util methods/ constants
Easily said with an example. Ex: To split domain name from user name use, MultitenantUtils.getTenantDomain(username);
Same applies for constants. Ex: MultitenantConstants.SUPER_TENANT_DOMAIN
ii. Use and expose OSGI services
You can simply expose any class you want by registering an OSGI service,
ex: In the bundle activator,
context.getBundleContext().
                        registerService(Foo.class.getName(), new Foo(), null);
Get a reference and re-use as pointed in point 2.
4. Understand Multi tenancy and design for Multi Tenancy
 
I feel that some folks don’t understand what multi tenancy (MT) means.  It is an important aspect of the platform and it should not be an after thought, but a part of the design.
Why do this?
 
Making code work for multiple tenants needs some careful design. It may not be straight forward for some cases. So thinking about it after a release or when you want to make the code work for MT may require some heavy refactoring. Now with the products and services merged, multi tenancy should not be separate at all.
How to do this?
 
This is an extensive topic so I will not go into details.
Using AxisConfigurationContextObserver, Tenant aware registries are some easy ways provided by the platform. If you are depending on a non-MT dependency, you will have to figure out how to make it work in the MT case. You can always get help from other folks who have done MT aware stuff.
 
5. Write tests for your code
Make sure you write tests for your code and gain a good % of code coverage. Folks will not know whether changes will break functionality or not until it is too late.
Why do this?
 
The reasons are obvious and have been stated by many. But to re-iterate, this makes the code base extremely stable. Other folks can change your code to fix bugs or do enhancements without worrying about breaking functionality or actually breaking functionality.
How to do this?
 

I personally prefer unit tests. But we have an integration test framework and as well as a system test framework (Clarity). Make sure you have tests to address to cover most functionality, if not all functionality. Features should not be considered complete, without test coverage.

 

If you find improvements on the points spoken, please do leave a comment and I will incorporate it into the post.

Shortcuts for Ajax calls in Jquery

This post should help a lot of people starting in jQuery and javascript. For ease of reference, I have borrowed code present in the ajax jquery docs.

The standard way in jQuery to make an ajax call is by using,

$.ajax({
  type: 'POST',
  url: url,
  data: data,
  success: success,
  dataType: dataType
});

This gives you an infinite number of tweaks that’s available (all documented here). But, the truth is 90% of the time you do not need these extra options. So, here are a few shortcut functions that allows us to write even less with jQuery.

$.post

Let’s take an example use of $.post:

$.post('bam_data_processor.jsp', 'processAll=true', function(data) {
  $('#hadoop_result').html(data);
});

This is shorthand for,

$.ajax({
  type: 'POST',
  url: 'bam_data_processor.jsp',
  data: 'processAll=true',
  success: function(data) {
  $('#hadoop_result').html(data);
}),
});

$.get

Now, let’s take an example use of $.get:

$.get('bam_stored_configs.jsp', function(data) {
  $('#hadoop_result').html(data);
}, "json");

$.get is shorthand for

$.ajax({
  url: 'bam_data_processor.jsp',
  success: function(data) {
    $('#hadoop_result').html(data);
  }),
  dataType : "json"
});

$.getJSON

An even shorter method for dealing with JSON is.

$.getJSON('bam_stored_configs.jsp', function(data) {
  $('#hadoop_result').html(data);
});

which is shorthand for:

$.get('bam_stored_configs.jsp', function(data) {
  $('#hadoop_result').html(data);
}, "json");

It’s really great that the jQuery devs introduce conveniences like these to write even less code. HTH.

Why write unit tests?

It was not until after a few years of being a dev that I understood why you need good unit tests. Unit tests are usually a pain, or so I thought. Why do you need to test the code, that you have already verified as working??

The problem comes when it’s maintenance time. And all code goes through maintenance either by you or someone else. Unit tests are a superhero when it comes to making sure any change does not break functionality. I understood this the hard way, I hope you don’t have to.

Here are some more advantages, that I personally like about unit testing.

  • You don’t have to build other components to figure out basic functionality has broken.
  • The code naturally improves using proper interfaces to accomodate unit tests.
  • If basic functionality is broken you know immediately.
  • You do not need to write features, copy/paste jars or dlls to know whether your code works properly.

If your a Java dev, here’s a great 60 second tutorial to start you off in JUnit 4.

Curl commands for testing REST based services

Curl is one of the best utilities for HTTP based testing. So, naturally, it’s a great for REST based services which are built on top of HTTP.

If you want to do HTTPS testing but not validate the certificate use -k

For basic auth, use --user username:password

For a url form encoded post use -d "foo=bar". If you just want to test out a post, use an empty string like -d "".

For debugging, use -v

Here’s a sample command I regularly use with a combination of the options above.


curl -k --user admin:admin https://localhost:9443/bam/ -v
* About to connect() to localhost port 9443 (#0)
*   Trying 127.0.0.1... connected
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* 	 subject: C=US; ST=CA; L=Mountain View; O=WSO2; CN=localhost
* 	 start date: 2010-02-19 07:02:26 GMT
* 	 expire date: 2035-02-13 07:02:26 GMT
* 	 common name: localhost (matched)
* 	 issuer: C=US; ST=CA; L=Mountain View; O=WSO2; CN=localhost
* 	 SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'admin'
> GET /bam/ HTTP/1.1
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.22.0 (x86_64-apple-darwin10.8.0) libcurl/7.22.0 OpenSSL/1.0.0e zlib/1.2.5 libidn/1.22
> Host: localhost:9443
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Wed, 13 Jun 2012 06:52:01 GMT
< Content-Type: text/plain
< Content-Length: 14
< Server: WSO2 Carbon Server
< 
* Connection #0 to host localhost left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
My Sample Text

Implementing Basic Auth for a servlet in an OSGI environment

You will first need to get a reference to the OSGI HTTP Service. You can do this through a declarative service. This post will concentrate on steps after getting a reference to the HTTP Service.

Note: The complete class for this post is located here

When registering a servlet through the OSGI HTTP Service, it provides you with an option to provide an implementation of HTTPContext.


httpService.registerServlet(alias, new MyServlet(), initParams, null);

When we implement the HTTPContext interface we can implement three methods. Out of these three (3) handleSecurity will be called before serving a request to ermmm… check for security.


public class BasicAuthSecuredContext implements HttpContext{
    @Override
    public boolean handleSecurity(HttpServletRequest request, HttpServletResponse response) throws IOException {
        return false;
    }

    @Override
    public URL getResource(String s) {
        return null;  
    }

    @Override
    public String getMimeType(String s) {
        return null;
    }
}

So, when implementing this, I’m borrowing a lot of content from the OSGI HTTPContext documentation and the HTTP Authentication spec. They are a must read, if you are interested in learning a lot, diving into details, etc. or you can just read the rest of this post.

First, it is a big no-no to do basic auth unless https is used. If it’s not there we let the user know it’s forbidden territory. Let’s go ahead and do that.

if (!request.getScheme().equals("https")) {
    response.sendError(HttpServletResponse.SC_FORBIDDEN);
    return false;
}

Next, let’s check for the Authorization header. If that’s not there we let them know, they need that shit to be there. Or we just say they’re unauthorized. Let’s do that now.

if (request.getHeader("Authorization") == null) {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
}

Ok, two tests passed. Now, we do some real work. Let’s extract the header decode it, and do “not so proper” authentication.

    protected boolean authenticated(HttpServletRequest request) {
        String authzHeader = request.getHeader("Authorization");
        String usernameAndPassword = new String(Base64.decodeBase64(authzHeader.substring(6).getBytes()));

        int userNameIndex = usernameAndPassword.indexOf(":");
        String username = usernameAndPassword.substring(0, userNameIndex);
        String password = usernameAndPassword.substring(userNameIndex + 1);
        // Now, do the authentication against in the way you want, ex: ldap, db stored uname/pw
        // Here I will do lame hard coded credential check. HIGHLY NOT RECOMMENDED! 
        return ((username.equals("username") && password.equals("password"));
    }

Let’s integrate this method, into the handleSecurity method. Notice how a meaningful error message is set to the response (line 14) when the security fails. This prevents the user from guessing, and they knows what exactly went wrong. Ermm, at least, if they know HTTP error codes they would know exactly what went wrong.

    @Override
    public boolean handleSecurity(HttpServletRequest request, HttpServletResponse response) throws IOException {
        if (!request.getScheme().equals("https")) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN);
            return false;
        }
        if (request.getHeader("Authorization") == null) {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }
        if (authenticated(request)) {
            return true;
        } else {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }
    }

That’s it. Now, pass this object when registering the servlet,

httpService.registerServlet(alias, new MyServlet(), initParams, new BasicAuthSecuredContext());

…and behold the power of basic auth in OSGI servlets!

Fixing the Class Not Found Exception when running a CXF JAX-RS service

If you are trying to deploy a CXF JAX-RS service inside an OSGI container, you can be haunted by the exception given below. But, surprisingly, the fix could be pretty simple 2 step process.

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
	at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:122)
	at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91)
	at javax.ws.rs.core.MediaType.<clinit>(MediaType.java:44)
	... 56 more
Caused by: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at javax.ws.rs.ext.FactoryFinder.newInstance(FactoryFinder.java:62)
	at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:155)
	at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:105)
	... 58 more

First, make sure you follow the steps to register your servlet through the osgi HTTP service as pointed out in the minimal osgi sample.

Then, the reason most probably would be a non-OSGIfied jsr 311 implementation present. Replace this jar with an OSGI compatible implementation located at org.apache.servicemix.specs.jsr311-api-1.1.1-1.9.0.jar.

That should (hopefully) solve your problem.