Saturday, December 26, 2009

Clojure Start Again

Clojure start again

It's my other attempt to learn Clojure.
The landscape has changed a lot since last time I took a look.

Toolbox

Some tools that I used to play comfortably

Building and dependency tracking

Most popular is unfortunately Ant in building Clojure. I'm not looking forward to editing build.xml files again.
But there are two alternatives that keep track of dependencies, and do packaging.

Leiningen - build tool

Leiningen is a build tool for Clojure designed to not set your hair on fire.
That certainly sounds nice. Installation is straightforward as well, following Zefs instructions does the trick.
It boils down to this:
cd ~/bin
wget http://github.com/technomancy/leiningen/raw/stable/bin/lein
chmod +x lein
lein self-install
Leiningen is wrapping up Maven2 in nice Clojure syntax and gives you by default access not only to Maven Central Repository but also clojars.org.

clojure-maven-plugin - build tool

Another option is clojure-maven-plugin Maven2 plug-in to help you out with Clojure.
Adding following snippet should get you started:
<plugins>
<plugin>
<groupId>com.theoryinpractise</groupId>
<artifactId>clojure-maven-plugin</artifactId>
<version>1.3</version>
</plugin>
</plugins>

Clojuresque Third option

Responses I received after publishing this post showed third option that I've missed.
It is used by ClojureQL and certainly has supporters. It lacks a bit of documentation but ClojureQL - Where are we (going)? describes process quite well.

IDE

There is quite some options here, following one is most popular amongst Clojure developers.

Emacs + SLIME

Well normally I use VIM, but after watching Dynamic Interactive Webdevelopment I took for a spin Emacs, well Aquaemacs.
Following two posts were very helpful in setting up nice environment:
After some problems that got solved by setting up swank-clojure-classpath my new IDE was up.
And it welcomes me with message: Connected. Your hacking starts... NOW!

Lets get learning Clojure.

Wednesday, October 21, 2009

Test your build with Maven 3

Maven 3 is coming

This post is to show you how to get Maven 3.
Maven 3 is supposed to be drop in replacement of Maven 2.
So you should be able to build your Maven based build with Maven 3 with no problem.
So lets take Maven 3 for a spin.

Getting Maven 3

You can get Maven 3 binaries or build it by hand.

Getting binaries

You can grab binaries from Sonatypes Hudson grid.
Depending on your platform:
Linux
lastSuccessfulBuild from ubuntu
Windows
lastSuccessfulBuild from windows
And extract it to your new M2_HOME.

Building from source

Check it out, and build:
$ svn co http://svn.apache.org/repos/asf/maven/maven-3/trunk maven-3
$ cd maven-3
$ export M2_HOME=/your/new/m3/home/
$ ant
So you have your own build of Maven 3 at /your/new/m3/home/. Congratulations!

Add to path

Independently how you got your new Maven 3, you need to add M2_HOME/bin to your PATH environment variable.

Start using it

And that is it, you have Maven 3.
As verification step execute, end expect something similar:
$ mvn -version
Apache Maven 3.0-SNAPSHOT (r828135; 2009-10-21 20:46:19+0200)
...
You probably will see quite some warnings while building your projects that previously where unnoticed.
Following those instructions will improve your build.
Enjoy your new build tool!

Wednesday, July 8, 2009

MOP version 1.6

It's been some time since I performed MOP release.

Quite a few things has changed in MOP:
With new release 1.6 that can be found in Maven Central Repository new configuration option has been introduced.

Let me introduce you to showVersion option :-)
showVersion

Thursday, April 2, 2009

Securing Grizzly Web Server

Running GrizzlyWebServer is very easy and lightweight. Serving HTTPS? The same.

It's just one more step to perform, provide Grizzly with SSL configuration.

But first thing first. Lets create GrizzlyWebServer telling it to serve secure content.
Just invoke this constructor:

/**
* Create a WebServer that listen for secure tls/https requests
* @param port The port opened
* @param webResourcesPath the path to the web resource (ex: /var/www)
* @param secure true if https needs to be used.
*/
public GrizzlyWebServer(int port, String webResourcesPath, boolean secure)
Say like this:
gws = new GrizzlyWebServer(PORT, ".", true);
If you would try start() now you get exception.
What is missing is SSL configuration.

Grizzly comes with SSLConfig helper class, that allows you to work with SSL configuration easily.
SSLConfig cfg = new SSLConfig();
This constructor fetches configuration from default properties locations, which are:
  • trust store - javax.net.ssl.trustStore
  • key store - javax.net.ssl.keyStore
  • trust store password - javax.net.ssl.trustStorePassword
  • key store password - javax.net.ssl.keyStorePassword
  • trust store type - javax.net.ssl.trustStoreType
  • key store type - javax.net.ssl.keyStoreType
If you need to override any configuration value, like key store location, just do:

URL resource = getClass().getClassLoader().getResource("test-keystore.jks");
if (resource != null) {
cfg.setKeyStoreFile(new File(resource.toURI()).getAbsolutePath());
} else {
// Couldn't find keystore, exit appropriately.
}
Once you have configuration ready give it to Grizzly:
gws.setSSLConfig(cfg);
And you are done, now do normal setup like providing GrizzlyAdapters and start().

Default configuration values are:
  • key store file - keystore.jks
  • key store type - JKS
  • key store algorithm - SunX509
  • key store pass - changeit
  • trust store file - truststore.jks
  • trust store type - JKS
  • trust store algorithm - SunX509
  • trust store pass - changeit
In case you want to authenticate your clients with certificates signed by your trusted CA you have to include CA public certificate in trust store.
Trust store configuration is as simple as key store configuration, methods just start with trust not key.

And that's how easy encryption with Grizzly is :-)

Saturday, March 14, 2009

Grizzly OSGi Http Service Guide

This post is an introduction to Grizzly OSGi Http Service.

Code for this post is available as Gitorial: http://github.com/neotyk/httpservice-gitorial/commits/master.

You'll find here:
  • how to use Grizzly OSGi Http Service
  • how to configure Grizzly OSGi Http Service
  • how to register servlet and resource
  • how to perform authentication on registered servlet or resource
  • what is currently implemented from spec and what is missing

Introduction

Grizzly

The Grizzly framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly goals is to help developers to build scalable and robust servers using NIO and we are also offering embeddable components supporting HTTP, Bayeux Protocol, Servlet (Partially) and Comet.

OSGi

OSGi is the powerful dynamic framework that underlies the Eclipse IDE and platform, but its use is not restricted to Eclipse. In fact it is used everywhere from mobile phone and vehicle entertainment systems to enterprise application servers. It is, essentially, the module system for Java.
It's lightweight and let's you escape JAR hell.

OSGi Http Service

The Http Service allows other bundles in the OSGi environment to dynamically register resources and servlets into the URI namespace of Http Service. A bundle may later unregister its resources or servlets.

Usage

Grizzly OSGi Http Service is available in two versions one with it's all dependencies and one by itself.
For version with dependencies you'll need to depend on:

For version without dependencies you'll need:

And examine its pom.xml to see dependencies that you'll need to satisfy.
Workspace with specified dependency on -bundle version is here.
Remember that even if you are using -bundle version you'll need to specify dependencies on org.osgi.core and org.osgi.compendium.
Next you'll need to configure bundle packaging as shown here.
Now you can configure your project to use maven-pax-plugin as specified here so you can do mvn pax:provision for easy startup of OSGi with your bundle and its dependencies provisioned.

Configuration

If you've tried mvn pax:provision from previous step you probably have seen exception that Grizzly OSGi Http Service couldn't bind to port 80.
Binding to port <1024 on most platforms requires special permissions.
Grizzly OSGi Http Service tried to bind to port 80 because it has not been configured to do otherwise, this is specified by spec as default.
To configure port that OSGi Http Service binds to you'll need to configure org.osgi.service.http.port property.
This configuration change is shown here.

Registration

In OSGi Http Service to expose something via http you have to register it.
But before you do it lets configure Declarative Services and Dependencies, this will allow much easier integration with OSGi Http Service.
Checkout this commit to see how to enable it.
Now that we have made our life easier lets get to registering Servlet and Resources.

Registering Servlet

To register a servlet you need to call HttpService.registerServlet method. Last two parameters (initparams and context) can be null for now.
alias is name in the URI namespace at which the servlet is registered,
servlet is servlet to register.
To see changes been done already, click.

Registering Resources

Registering resources is way to expose static content in OSGi Http Service.
To register resources you need to call HttpService.registerResources method. Last parameter context is optional and can be null for now.
alias is name in the URI namespace at which the resources are registered,
name is the base name of the resources that will be registered.
For working example go here.

Authentication

So far registering dynamic and static content has been described, that is nice but what if you would like to secure it?
Sure thing, you just need to provide last parameter (context) to resource/servlet registration.
If you don't provide context default context is used and this one is allowing all access.
Your authentication have to be implemented in HttpContext.handleSecurity.
This method is called by OSGi Http Service before request is handled. If your implementation returns true the request should be serviced, false if the request should not be serviced and Http Service will send the response back to the client.
And you probably saw it coming, here is a code for it.

Status

Not all specification has been implemented.
Things not implemented yet are:
  • SSL support,
  • Security as described in 102.8 Security
Those things will get implemented if users will be interested in it.
Rest was implemented as specification requested.


Enjoy working with Grizzly OSGi Http Service and make sure to report issues as well as success stories to Grizzly Users List.

Thursday, February 26, 2009

Clojure?

Just finished watching Clojure for Java Programmers.
Second part is much more interesting.



If you like Clojure you might want to take a look at Clojure on Grizzly.

Tuesday, February 3, 2009

Monday, January 12, 2009

Maven Archetype Automation 1

In my need for automation I found another place for improvements in Maven2.

Here is a situation: you have sample project showing how to use something.

And you want to be nice to your users so you would like to offer them this sample project as archetype via archetype-catalog.xml.

Here is a bit longer version of above:


ArchetypeNG seems like possible solution, have to research this one.