Tenth Coimbra JUG Meeting – Maven Introduction

posted by Roberto Cortez on

Last Wednesday, 4 November 2015, the tenth meeting of Coimbra JUG was held at the Department of Informatics Engineering of the University of Coimbra, in Portugal. The attendance was great. We had around 40 persons and a lot of them were on a Coimbra JUG meeting for the first time. We had the pleasure to listen Sérgio Ferreira talk about Maven. Sérgio is an old time member of Coimbra JUG and he volunteered to present the session for us for the first time. A big thanks to Sérgio! It’s not easy to do it.

Love it or hate it (and a lot of people seem to hate it), Maven is a widely used tool by 64% of Java developers (source – Java Tools and Technologies Landscape for 2014). Most experienced developers already got their share of Maven headaches. Usually in the hard way, banging with their head into a brick wall. Unfortunately, I feel that new developers are going through the same hard learning process. In a young JUG as ours, it makes perfect sense to have a dedicated session to Maven, since sooner or later everyone will have to use Maven.

Coimbra JUG Meeting 10

As always, we had surprises for the attendees. IntelliJ sponsored our event, by offering a free license to raffle among the attendees. Congratulations to A. Ventura and Ana Filipa for winning the license. Develop with pleasure! We also handed a few Tomitribe and ZeroTurnaround t-shirts.

Here are the materials for the session:

Also, we already have our 11th and 12th Meetings scheduled for 2 and 9 of December of 2015. These are going to celebrate our 2nd Anniversary and we are happy to have two international well know speakers: Heather VanCura and Christoph Engelbert. Please, check our Meetup website for more information.

Enjoy!

Reduce Legacy from Java EE 5 to 7

posted by Roberto Cortez on

Code from Another TimeJava EE 5 was first introduced in 2005, while Java EE 7 came out in 2013. There is a 7 year gap between both versions and in technology terms it’s like a century.

Many organizations are still stuck using Java EE 5 and there are many valid reasons why they choose not to upgrade. Still, these become irrelevant if you look into some of the reasons to move forward:

  • Benefit from the Latest Improvements
  • Java 6 EOL in Q1 2013
  • Increased Maintenance Costs
  • Hard to keep Developers interested

These reasons are somehow debatable and may not be enough to convince someone to upgrade.

Over the last few years, I’ve worked in an application with a considerable dimension and just recently it was migrated from Java EE 5 to 7.

Stop the Legacy

Code Grow Graph

Every year, new features were introduced that increased the application code base. It even surpassed 1 Million lines of code! This fact alone is an indicator that it’s hard to navigate this huge code base. If the application keeps growing, this will only get worse with time. Since the beginning of the application inception, we can observe that the grow was steady with each year, until 2015, when the migration happened. Afterwards, the code still grew but at a slower pace.

How?

In fact, by changing to Java EE 7, it was possible to produce the same results, but by writing less code. This may not seem a very big deal with small applications, but when we are talking about 1 Million, it makes a huge difference.

Not only you are being more productive, by consuming less time to implement the same feature, but also the chance to introduce bugs is smaller, since you also have less code to mess around.

No one really wants to change old code, especially if it’s working and even worst, you don’t know exactly why it’s used. But there are a few easy to use features from Java EE 7 (and 6), that you can use straight away when moving from Java EE 5.

CDI

Remember the tedious work to get an EJB in a different context, like a Servlet:

Most of these can be simply replaced with @Inject.

No more Local Interfaces

Tedious to always have to define an Interface for your Beans, especially if they were only used locally:

Just Replace by:

Singletons

Old fashioned Singleton (maybe not the most correct way to do it):

You just change it to:

Validations

Since you didn’t have Bean Validation available in Java EE 5, sometimes you had to resort in doing things like this:

Now we can just use @NotNull and @Max annotations into the field that we want to validate.

JMS

It’s a pain to use JMS in Java EE 5:

With JMS 2.0 and Java EE 7 you can drastically reduce the code and use chaining calls:

Moving Forward

These examples are just the tip of the iceberg on how you can simplify your code. There are many more examples, but these are the main ones used in this project.

Please post your examples in the comments section.

Also, if you would like to learn more about check my session, Migration Tales from Java EE 5 to 7 which covers some of the solutions we had to implement to completely migrate an application. Each case is different and there is no right recipe, but it can give you a good idea on the path you need to walk to achieve your goal.

Slides:

Video:

Multiple Tomcat Instances

posted by Roberto Cortez on

Multiple Tomcat InstancesWhen building a real application you often find yourself having to deal with different stages of the software. The most common stages are development, testing and production, but you can have many more. This means that you need a different environment to deploy the application on each of the current stages. You use different environments to be able to perform versioning, different configurations, test bug fixes and so on. This also poses challenges on upgrading environments, changing shared configuration or keeping track of the servers. I will show you how to do it with Tomcat.

The easiest way to set up multiple Tomcat instances is to duplicate the entire Tomcat folder and change a few configurations. I don’t advise doing it this way, since it’s harder to maintain, harder to spin up new instances and harder to upgrade. Instead, we will set up the instances in a much more flexible way, by duplicating only a few things and keeping a shared base folder for all instances.

Installation

You need Tomcat of course. Download it here.

I’ve used version 7.0, but this should also work with other versions. I’m also doing the setup in a Unix like environment. This can also be accomplished in a Windows box, but the commands need to be adjusted.

Unzip the installation folder to a directory of your choice. I just recommend to do it in a parent folder and you can use a name like tomcat or server.

Now, instead of using the unzipped folder, we are going to create a link to it, like this:
ln -s apache-tomcat-7.0.64/ current

Here is a sample:

Setup

To keep this simple, we are going to create two instances: development and production. But keep in mind that you can create as many as you want by making the necessary adjustments to the scripts.

Folders

Create a folder now named instances or environments. Inside, create a folder named development:

Now copy the folders conf, logs, temp, webapps and work from the Tomcat install folder into development and production:

If you wish, you can now remove these folders from the Tomcat install folder, but is not mandatory.

Home and Base

The idea here is to share the main Tomcat folders and each instance has a copy of their personal folders to not clash with each other. Tomcat defines two environment variables called CATALINA_HOME and CATALINA_BASE that allow us to do that.

Create a bin folder in the instances development. Add the following exec.sh script:

Note: If you are using MacOSX, you might need to install core-utils using brew and replace readlink by greadlink to achieve the proper behaviour.

This script is going to set up the proper configuration variables to point to our shared Tomcat and the specific instance folders. Note the properties http.port, https.port, ajp.port and shutdown.port are included in the CATALINA_OPTS environment variable. With these we can pass specific configuration to the server.xml file. Tomcat is smart enough to perform property replace substitution as long as you have the proper placeholders in place.

Files

All these operations are performed in the development folder instance.

conf/server.xml

Edit the file conf/server.xml do the following changes;

ReplaceBy
8080${http.port}
8443${https.port}
8009${ajp.port}

Note: Unfortunately the only place where property replacement doesn’t work is the shutdown port. I think this is a bug in Tomcat and should be fixed. So for now, we need to keep it hardcoded.

bin/exec.sh

On the bin folder, create links to exec.sh to the following files: catalina.sh, startup.sh, shutdown.sh.

This will allow you to call the original Tomcat, but by calling the exec.sh set up first. The magic is done by the line $CATALINA_HOME/bin/"$(basename "$0")" "$@" in the exec.sh script.

Run

The instance should be ready to be executed. Just run it as you would do it normally by executing sh catalina.sh run or sh startup.sh from the development instance folder.

Additional Instances

Just duplicate the development instance folder to a production one and edit the bin/exec.sh to update it with different ports. You can user 7080 for http, 7443 for https, 7009 for ajp and 7005 for the shutdown.

Since property replacement is not working properly for the shutdown port, we need to manually edit conf/server.xml from the production instance and replace 8005 by 7005. When this bug is fixed, and you actually use a property, you don’t have to worry about doing this.

Note: You might need to reestablish the proper links in the scripts catalina.sh, startup.sh and shutdown.sh stored in the bin folder.

After this, your second instance production is ready to run. If you need more, just repeat the last steps, making sure to pick ports that don’t conflict with the instances already set up.

Perks

With this set up you can now:

  • Create new instances easily with minimum changes. You can actually have one untouched unchanged instance, that you can use to copy from to create others.
  • Update the Tomcat version, just by installing a new distribution and updating the link to current.
  • If you place jars in the libs folder of the HOME installation, they become instantly available to all instances.
  • Instead of duplicating the conf folder, you can actually link to the one in HOME and also share the configuration between all environments. Or just link to the files you want to share.
  • Remove an instance, by just deleting its BASE folder.
  • Also works for TomEE!

Alternatives

If you don’t like this set up, you can try using Docker. Check the following post: Get Into Docker.

Let me know if this was useful to you or if you had any trouble following the blog instructions!

Ninth Coimbra JUG Meeting – CDI: How do I?

posted by Roberto Cortez on

Last Thursday, 9 July 2015, the ninth meeting of Coimbra JUG was held at the Department of Informatics Engineering of the University of Coimbra, in Portugal. The attendance was great. We had around 30 persons and considering that July is a month where a lot of people go on vacations, we can’t complain. We had the pleasure to listen to António Gonçalves talking about CDI. A great opportunity to interact with one of the greatest experts in CDI and Java EE in general. The best of all: it was in Portuguese!

In my opinion, CDI is a specification with great potential. It will probably become one central piece of all the other specifications in the Java EE world if is not already. For that reason, it makes sense to dedicate sessions to CDI CDI. Even more, when a lot of developers don’t know it is out there and others use little bits, without knowing that they are using CDI. Not many people from the audience was using CDI. António, demonstrated some of the core features of the specification. With the help of JBoss Forge, António created a small web app and showcased Dependency Injection, Qualifiers, Producer, Scopes, Alternatives and Events.

Coimbra JUG Meeting 09

As always, we had surprises for the attendees. IntelliJ sponsored our event, by offering a free license to raffle among the attendees. Congratulations to Vitor Loureiro for winning the license. Develop with pleasure! We also handed a few Tomitribe and ZeroTurnaround t-shirts.

Here are the materials for the session:

Enjoy!

Devoxx UK 2015 – The League of Extraordinary Developers

posted by Roberto Cortez on

The third edition of Devoxx UK 2015 was in London, between 17th and 19th June. This was my first conference since I joined Tomitribe. The dynamics were a little different for me this time. I actually had a triple role: attendee, speaker and exhibitor. Since Tomitribe was also sponsoring the event I had to spend some time at our booth to interact with other developers using TomEE and to promote to the ones that don’t know it yet. During that time, we also worked to push out the latest release of TomEE with most of the Java EE 7 support!

Venue

Devoxx UK 2015 VenueDevoxx UK was held at the same location as last year: The Business Design Centre. This year, more rooms were available, since the number of attendees was also higher. I don’t have the exact number, but I guess that close to 1 thousand might have attended the event. The Exhibition Hall was more or less the same, but I was surprised to see that some usual sponsors didn’t make it this time. The Community Hall pretty much had a non-stop Hackergarten well managed by Heather VanCura. By the way, what is wrong with the picture? I rule as a photographer, right? 🙂

Sessions

The program was interesting enough, a lot of diverse subjects and you had five options to attend on each scheduling bracket. I was not always into sessions, since I also needed to spend some time in the Exhibition and Community Halls. Not a problem, because all the sessions were recorded and are going to be available on Parleys, which is cool. These are my top 3 sessions (from the ones I have attended):

You should get the first two sessions on Parleys. But the third one is already available:

Also, have a quick look to this awesome Ignite Session by Tonya Rae Moore:

My Session

I’ve got to speak about the Five Ways to Not Suck at Being a Java Freelancer. It may sound a little strange, since I’ve put the Freelancer life on hold. I’ve submitted the session before that event and I think it’s still valid to provide some of my experience during my Freelancer life. Here is a session about it:

vJUG Reading Club

This is not exactly related to the conference itself, but since I was in London I’ve met with my good friend Simon Maple to conduct our second Book Reading session. If you are not aware, vJUG started a new initiative: the Book Reading Club. The idea is for the attendees to gather around a book, read it and discuss it. We started with the awesome book Effective Java by Joshua Bloch. We had our second meeting around the book and it was fun to hear Josh explain some of the decisions made around the development of the Collections API, Generics and For each statement. A must see:

Community

The Community was awesome as always! This time I had the pleasure to have with me some very good friends from Portugal:

Devoxx UK 2015 PT Community

Hackergarten

When thinking of stuff to do in the Hackergarten, I had the idea to write a small piece of code to perform Method Caching using the new JCache API. I’ve soon discovered that I’ve gotten beaten by Andy Gee (no hard feelings). Anyway, we had some interesting discussions about it with Bruno Baptista and Sebastian Daschner. Check the result: JCacheExamples.

Java EE BoF

Also on the Java EE BoF we had the usual discussion between Java EE and Spring. In my honest opinion, I think this discussion is pointless. Both technologies can be used together and everyone is free to pick the parts that fit their project more. On the other hand, I think that Spring has done a fantastic job with Spring.io website. Java EE has a lot of information, but it’s all spread around the Internet. I believe that this causes a bad impression to new developers and in the end they may end up favouring Spring more.

Also, the adoption of Java EE 7 has been slow in the organizations. There is no Application Server support yet and companies are lacking the resources to perform the migration. I’ve personally been working in a Java EE 5 to 7 migration and I intent to make a session about it.

20 Years of Java

Do you have any idea what was going on when Java was born?

Devoxx UK 2015 Java 20 Years

During the event, there was a lady taking polaroid pictures of developers. These pictures went into a wall and organized by the year you wrote the first line of Java code. I remember that it was in 1996 for me. I was writing an HTML website, but was unhappy that I couldn’t do any kind of dynamic behaviour. Searching on the web, I’ve found the solution: Java Applets! I bought a book called “Learn Java in 30 Days” and I wrote my first line of Java in the Notepad. I wondered where was IntelliJ at that time!

Final Thoughts

That’s all! Hope you enjoyed this report. Cya next year!