Monday, March 02, 2015

Java EE7 and Maven project for newbies - part 8 - #js2.2 with @primefaces 5.1 setup on @WildflyAs 8.2 using #maven

Series

 

It's been a long time since my last post, for this series of  tutorials. Its time to resume and add new features on our simple project. As I have mentioned in previous posts, this series of posts is targeting mostly Maven and JavaEE7 newcomers, I welcome any questions or comments (and fixes) on the contents below. I promise I will try to keep up with the updates.

Git tag for this post?

The tag for this post, is this post8, and can be found on my bitbucket repo

What has changed from the previous post?

  • Some comments and fixes on the code from readers have already been integrated.Thank you very much all for your tome.
  • I have updated the Wildfly Application Server version from 8.1 to 8.2, so all the examples and code runs under the new server.
  • I have also updated the versions of the Arquillian BOM (s), to the latest version which is now 1.1.7.Final
  • I have also added a property under the sample-parent project that indicates the path that the various maven modules will download and use Wildfly server, automatically so that you don't have to download it on your own. The server will be automatically downloaded and extracted to the predefined path, as soon as you try to execute one of the unit tests from the previous posts (sample-services module)

Adding a JSF enabled war Maven Module on our ear

Eventually our project structure already featured a war (see sample-web) maven module. So there is no extra module introduced rather than changes on the existing pom.xml files of the parent and the module itself. 


Step 1  changes on web.xml

Our  application server is already bundled with the required libraries and settings in order to support applications that make use of the JSF 2.2 specification. Wildfly bundles Mojarra 2.2.8. What we have to do is just update some configuration descriptors (eventually only one). The most important is web.xml which now looks like this.

Step 2 Packaging of war and the skinny war issue

Our war module, is following a packaging scheme called skinny war. Please read the following page from the Apache maven war plugin. To cut a long story short, in order to reduce the overall size of our deploy able (ear), we package all the required libraries under a predefined folder on the ear level, usually is called \lib and we don't include libraries under the war's WEB-INF\lib folder. The only thing you need to do, is add those dependencies of your war to the ear level. Despite the fact that the overall 'hack' does not feel very maven like, it works if you follow the proposed configuration, but there are cases that skinny war packaging wont work. One of these is usually for JSF based JavaEE web applications where the implementation of the JSF widget engine should be packaged within the war's WEB-INF\lib. 

For our sample project, I am using the excellent and free Primefaces library, which I highly recommend for your next JSF based project. So I need to define a dependency on my war module for the primefaces jar but by pass the skinny war mechanism only for this jar, so that it is packaged in the right place. This is how we do it.


Step 3 Add some jsf love, a managed bean and an xhtml page with the appropriate tags.


Our code is just a small table, and a couple of tags from Primefaces. If you think that you need to read more about JSF 2.X please have a look on the following links

Step 4 Package and deploy to a running server.

Start your wildfly (you are expected to have one under your project-base dir and the subfolder servers

<wildfly-server-home>${project.basedir}/servers/</wildfly-server-home>
 
and then under the sample-parent project type.

mvn clean install -Ph2

You should have your demo JSF 2.2 enabled demo app, on http://localhost:8080/sample-web/ and see something like the following.



That's all, this will give you a simple start in order to expand on something more than a demo!

As always you will find the complete - example under tag post8 .

Tuesday, February 17, 2015

Java Testing with Spock...introducing #spock #manning #java #book



Well tested code  is a concept that many developers talk about every day, lots of great authors write books and articles around it, several tools are being developed that aim to help developers to do it faster and efficiently.

Despite all the above, testing is something like a lost art, many development teams ignore it, do not do it at all, or it is considered as a waste of time!!! Look no further, poorly tested code (and systems) is one of the major reason that many of our software projects and code fail now-days. 

There are a few people that I have worked with all these years, that stick to their principles regarding quality in the code, testing and continuous refactoring. One of them is Kostis Kapelonis, who I had the pleasure to work with a couple of years ago under the same corporate roof, and is actively involved in our small Java community here in Athens.

 If the name sounds familiar, then most probably you might have attended one of his many presentations during our local Java User Group here in Athens or red some of his articles in InfoQ. A couple of weeks ago, Kostis sent  an email asking for help on reviewing his first draft chapters on an upcoming book, around Spock, another cool and interesting tool, that aims to take it's place (hopefully) in our every day testing tool set as Java developers.

Despite the fact that I still have not used Spock in my day job (projects), reading these  drafts chapters helped me discover a new tool with similar concepts comparing to tools I am already familiar with  eg Mockito, Jmock + a yet another reason to study Groovy. I always enjoyed Kostis's presentations and I find his writing simple and clear.

So if you love well tested code, if you love Groovy or you feel that your current testing tool set does not cut it towards your needs, have a look on Java Testing with Spock which currently has just entered the MEAP 'phase' in Manning. Maybe Spock is something you should review and assess, so why not let an expert guide you through the process!

: ) 
 

ps) 

I am very very happy and proud that the list with Greek book authors (especially Java freaks, is getting bigger), my other fav one is Patroklos. I hope one day to join them as well!






Sunday, February 01, 2015

How to install 3 popular NoSQL databases for development in MacOSX for newbies Part 3 (CouchBase ) #nosql #couchbase

In this post we are going to install CouchBase, a NoSQL database that has gained a lot of momentum latetly. CouchBase is very very developer friendly in terms of setting up and getting started time. Actually is the simplest. It offers a single download for many platforms (including MacOSX). You can find them here.

It is dead simple, as already described in the instructions. Just download, unzip and move the CouchBaseServer.app to your Applications folder or anywhere else you like. Done!

In order to start the server just double click on the .app, and a small icon will be loaded on your top right corner of the menu.

 The server will start and by pressing the Open Admin Console link, you will be redirected to a web page with the Server's Admin console (http://127.0.0.1:8091/index.html)




That's it, the admin console, offers you similar functionality to a GUI client, so you can review and manipulate your buckets, views etc!

Easy! So easy that you must try it!!! : )