Run Gradle Builds on OpenShift

OpenShift has supported Apache Maven as default build system for Java based projects since the first release. All the Java projects created by OpenShift are maven based. A few months ago we also added support for Apache Ant. All OpenShift gears now have Apache Ant installed on them. So, using Apache Ant to build your project is as easy as updating the OpenShift build action hook. You can refer to my blog post to learn how you can use Ant to build your OpenShift projects.

Lately I have seen lot of developers asking how they can use Gradle to build their projects. Gradle combines the power and flexibility of Ant with the dependency management and conventions of Maven into a more effective way to build. A lot of open source projects and enterprises are using Gradle as their build system. The Spring Framework is one popular example of an open source project using Gradle. In this blog post, we will learn how we can configure an OpenShift Java project to use Gradle instead of Apache Maven to build the project.

Read full blog here https://www.openshift.com/blogs/run-gradle-builds-on-openshift

Download OpenShift Origin Virtual Image

In case you wish to download OpenShift Origin virtual image using wget and get the error shown below then you should use command shown below.

Connecting to mirror.openshift.com|184.72.214.144|:443... connected.
OpenSSL: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
Unable to establish SSL connection.
wget https://mirror.openshift.com/pub/origin-server/release/3/images/openshift-origin.zip --secure-protocol=SSLv3

If you wish to use another name for the file, you can use –O option as shown below.

wget --O openshift_origin_3.zip https://mirror.openshift.com/pub/origin-server/release/3/images/openshift-origin.zip --secure-protocol=SSLv3

How to build Java WebSocket Applications Using the JSR 356 API

It is a well known fact that HTTP(Hypertext Transfer Protocol) is a stateless request-response protocol. This simple design of the HTTP protocol makes it very scalable but inefficient and unsuitable for highly interactive real-time web applications. HTTP was designed for document sharing and not for building today’s highly interactive web applications. HTTP is bit chatty in nature, as for each http request/response, a lot of headers need to be transmitted over the wire.

Before the HTTP 1.1 version, every request made to the server resulted in a new connection. This was improved in HTTP 1.1 with the introduction of HTTP persistence connections. Persistent connections allowed web browsers to reuse the same connection for fetching images, scripts, etc.

HTTP was designed to be half-duplex which means it allows transmission of data in just one direction at a time. A Walkie-talkie is an example of a half duplex device because only one person can speak at a time. Developers have created some workarounds or hacks to overcome this HTTP shortcoming. Some of these workarounds are polling, long polling, and streaming.

You can read full post at https://www.openshift.com/blogs/how-to-build-java-websocket-applications-using-the-jsr-356-api