Docker and Mule

So I've been looking in to Mule ESB (Enterprise Service Bus) for my new job.

After testing it, it seemed like a lot of fun. Another of my projects was to learn Docker (scorching hot right now).

So I thought "Why not combine them?", little did I know that I was in for a world of Internet-searching, documentation exploring and more.

So first some more Info on Mule and Docker:

Mule ESB

http://www.mulesoft.com/

Is kind of an adapter between services. It's message-based and has a lot of functionality already done.

Ex: Say you have a Java site that needs paypal. Mule can sit between, take the request by JMS, HTTP and more and pipe it to paypal and then back again. Maybe you want a facebook post for every 1000 visitor? No problem.

Why do this when you can code it your self? One of the reasons is that you can use much of the code again, you can separate some of the work to this Mule server or you can do a microservice style and have Mule be the glue between them all.

Docker (Docker.io)

https://www.docker.com/

Docker is a way to make Linux Containers (LXC) manageable and share-able. It's a technology for making small VM's where you can isolate you app.

Why? Say that your a developer. Your app works in your developer environment. But that's not always the case for the production environment. 

What if you could have a environment under development and just ship the whole environment? That's what you do with Docker.

It's also a good subject if you want have microservice's, every service can have its own Docker Container. 

And it's scalable, you can have servers with CoreOS (made for running in HUGE clusters, we're talking Google-size) and run your Docker Container.

Cause that's one of the best perks, your Docker Container runs ANYWHERE where there is a Docker Engine. You can develop under Windows and Mac with boot2docker via Virtualbox and then Deploy to a real Linux Server running Docker Engine.

 And people share many of their Docker Containers via buildfiles (DockerFile). You can have your own private registry of Images or use the Central DockerHub.

My Problem

So there is a couple of people that have done Docker Containers for Mule Server.

And I could not get this to work!

I was a rookie at Docker so I blamed my lack of knowledge.

I followed the guide and it would not work.

The regular Mule Server and my test app work perfectly.

The Docker version blocked the right ports, but it would not give me a response.

I scratched my head...

Spinning up a Wildfly server in docker was 2 commands and it worked perfectly. 

So I compared the DockerFiles, but nothing looked weird. Was there something special with Mule?

But why? The creator seemed to get it to work without problem.

After that I found a solution!... Or so I thought. I was able to publish the port so I could run and get a response...from localhost but not from a remote computer.

But wildfly worked with the remote computer, what was the difference???

Frankly I thought I was missing a puzzle piece with Docker, like firewall, config or something.

After 2 weeks of leaving and coming back to it (Googled some on breaks at works, coming up with new ideas what it could be) I finally found the answer.

After being really frustrated I started to really look at the test app and compare it to the Docker Container Creators test app.

My app said that localhost should run the http start-point, the other app said 0.0.0.0....

OF COURSE! So I was looking at the wrong place!

I thought I made the simplest test app ever, a little hello world, but I succeeded in not doing it correctly. 

After changing it to 0.0.0.0 it worked flawlessly. So simple that it's extra hard to find.

But on the up side I learned A LOT about Docker and how to use it.

So I can recommend Docker and Mule, Docker is not as hard as some think, just know what your putting in it before blaming Docker.

Code ahoy!

Spring MVC Step 1

So I've been digging around Spring. It's a very versatile framework. So you might need to research which parts you actually need.

I'm into Java EE Web so I want the core-part and the web-mvc (yes they actually have a subproject tailored to MVC on the web).

So I went and found the easiest tutorial I could find. Some tutorials are great but they give you like 50 classes from the start. If you'r trying to learn Spring then you might want to know if all the classes are needed or not.

But I found one that was small with good explanations (http://examples.javacodegeeks.com/enterprise-java/spring/mvc/spring-mvc-hello-world-example/)


So I will first show my setup (I use Gradle instead of Maven like the tutorial uses).

Folder-Structure

Project
--src
----main
----test
--build.gradle

The src just hade a package structure for one class, the HelloWorldController.java
Right now the test-folder is empty, it will be used for future junit-tests.

build.gradle:

The rest is identical to the tutorial. If you want to run it in a Wildfly-server (the tutorial uses tomcat), you just run "gradle assemble" and either copy the war to the deployment-folder or you can use the web-managment and deploy it there.

So now some explanation of how it all binds together:

DispatcherServlet

The most central part is the DispatcherServlet. This is a servlet that Spring have created to mediate all the traffic. The http-request come to dispatcher and it then uses the RequestMappings from the controller-classes to retrieve the right view and model.

It reminds me a bit of the FacesServlet that all the facelets with JSF goes through.

So in web.xml you define the DispatcherSevlet just like you would do any (before the Annotation-trend started) and map it to the "/" url-pattern.

When you define the DispatcherServlet you may pick a name for it. It will then look for this name as a xml file: "name-servlet.xml" in WEB-INF.

So what would we set up in this xml? How the dispatcher will resolve the connections.
You can define all the components one by one, do a component-scan or a component-scan via Annotations (not in the xml).

In the tutorial (which I also use) they defined a bean, in this cause a bean of "org.springframework.web.servlet.view.InternalResourceViewResolver". This will be used to resolve the views.

In it we set some properties:
prefix: the folder where the views are.
suffix: .jsp

This makes it easy for the classes. They can return a String "hello" and it can be resolved to /WEB-INF/views/hello.jsp". This makes the Controller classes more readable.

Then we need a Controller to actually do anything. I put a "index.jsp" that just says welcome. It shows when the "/" url is requested. My web-app folder structure looks like:

Controller

A controller is a class with @Controller annotation. It is likely that you want the @RequestMapping("/hello") also. 

You can then do a method that returns a String. This method should have the @RequestMapping(method = RequestMethod.GET) annotation. This only registers so that when a request is used via GET, this method is returned. 

This means that you can have seperate methods for the others ex. POST

You can now return "hello" or "helloWorld" depending on what you named your jsp-file.

Conclusion:

We need:
A web.xml which configs the DispatcherServlet
A dispatcher-servlet.xml which configs the view-resolver.
A Controller

The dispatcher will register all the mappings from the controllers and direct the traffic.
The controller will return the name of the view to the view-resolver which puts prefix and suffix on it.

If you put your views in the WEB-INF users can't directly request them, they have to use the url-mappings of the controllers, which is a very good thing.

(EDIT: and after the ViewResolver sends it back to the dispatcher the dispatcher sends the html to the user that requested it)


So that's the first step in Spring Web MVC. I find Spring very interesting and will continue to learn and explore. I will continue to use Wildfly and Gradle. One of the things I want to do is an automatic deployment without a IDE. You can do this with Cargo-plugin but I want to find a different way.

Happy Coding!

Early Spring

I'm almost done with my first real Java EE project (JSF, JPA, Wildfly) and its currently running on a raspberry pi.

My next project will be learning the Spring Framework.
I will also try to do some post about how to start with Spring.

Initial impression:

My first impression of Spring is that its a well made framework that fills every part of your development (specific test-suite and more). The different modules of the framework really gives you a good feeling of security for functions.

But there is a big step for a newbie to just jump into Spring!

First problem: Overview

What does what and how "do they want you to code". With pure Java EE you can do as you want,

but in Spring there is a certain way "they" want you to code. I'm not saying it's bad. But there is a problem of learning it.

Second problem: Too big tutorials

Many of the tutorials start to big with 20+ ready to use classes. And the tutorial uses these classes. This makes you feel like you jump into the middle of things and not understand the whole process.

Third problem: Spring Boot

Lovely little thing that really can kickstart your project, but it doesn't help you in understanding much.

Fourth problem: Name usage

Some of the names conflicts with pure Java EE7 names. A Spring Bean is configured differently then a regular Bean that can be Dependency Injected.

Dependency Injection in Spring is different then Pure Java EE7. EE7 has @Inject while Spring uses @Autowired that usally is a Interface that a config-class or a xml has mapped to a implementation class.

So that's some of the hurdles a rookie will deal with.

On of the links I've found useful (haven't had time to read to much yet) is: springbyexample.org/examples/core-concepts.htm

This site ACTUALLY explains the core concepts.

So when I have some more information about the core concepts that are essential I will make a post about it.

Happy Coding!

TDD - Test Driven Development

Intro:

One method for coding stable code is TDD.

The basis of TDD is to write the test first, test it (and get an obvious fail) and then write the implementation.

Why would you do it this way?

First:
Because you implement the classes as a request-contract.

Second:
You have value full tests to-go

Third:
With these tests, if you refactor code hopefully your test will alert you for any breakage

My Story:

I started on a project (Java EE 7 with JSF) and wanted to practice junit tests. But for Injected beans and Jsf-contexts, the story got tricky.

Now the Great test framework Arquillian has all the answers for that, BUT some of the things you need is only in alpha state. I struggled with it a lot. So much I actually choose not to do any tests...

BIG MISTAKE!

So when I tried to code a function for deleting a certain thing from the database (in the middle of relations) i got some problems. Every time I changed the code, I had to log in, navigate to the right site, try the function and then try to understand the giant EE stacktrace.

So I did a GIANT Refactoring (actually starting a new project and just copying in the entities).

I tried for 2 days to implement all of Arquillians might for testing actual websites in the server (Graphene, Selenium, Drone). But in the end it didn't work.

But I got the junit tests (run by Arquillian) to work (as injected beans).
So now I could actually test the beans function without all the login and stuff.

And when it's all implemented I can actually do manual Selenium tests to see that it actually works in the website.

A bonus thing is that the test wipes and then populates the database with test-data.
So if I have to drop the database (ex if I change the persistance classes) I don't have to create all the test data manually.

Summary:

So what can we (and especially I) learn from this?

Even if you don't do the tests first like TDD, have a test framework! It saves so much time.

Code ahoy!

ManagedScheduledExecutorService and Wildfly

So I needed a task to be run once every day. I needed to check if a user had 7 days left of the membership (and mail her/him a notice) and I needed to remove the users and the connected stuff if a members membership had expired.

I thought I would use a cron-job (linux for the win!). But I had made these nice functions with JPQL that retrieved all the users that had the requirements.
I actually stumbled upon the solution quite quickly but boy did it take some annoyance to get it right.

The answer was ManagedScheduledExecutorService. That's a mouthful.
This is a Java EE7 specification so the servers need to implement it to call them selves EE7 Application servers (the web-profile-only servers doesn't count).

With this you can schedule a task (any POJO that implements Runnable which is Java 101).
You can set it to run once, with fixed intervals or fixed delays or you can implement a Trigger (a interface) that sets of at certain times or conditions.

I went for the intervals and Wildfly. Now with Wildfly you can either use the standard config for ManagedScheduledExecutorService or you can config you own. I choose to config my own because the standard one had several threads (4 I think) and I only needed one.

This was done in the config of the server (standalone.xml/domain.xml).
You can also config the threadfactory there.


<managed-scheduled-executor-service name="removerScheduledExectutorService" jndi-name="java:jboss/ee/concurrency/scheduler/RemoverScheduledExectutorService" hung-task-threshold="50000" core-threads="1" keepalive-time="5000" reject-policy="RETRY_ABORT"/>


With the long jndi It actually shows up in the Wildfly server managment interface,

Problems

So I had two problems:

1: My intervals wasn't working at all... For some reason it started 3 threads that ran 3 seconds after each other (I had 15 seconds intervals for testing). And then all 3 threads had 15 second intervals between there own executions. I made it print out the threadId and it was the same for all 3 threads.
So either all threads where doing something weird or I had one thread doing intervals very wrong.

Somehow Netbeans deployment annoyed the server. For when I restarted it without deploying a new version, the services actually kick in right. I also tried to do a classic boolean-switcher from the bean that scheduled the tasks, don't really know if it helped or not. But my intervals was working now.


2: I @Inject my facades to the database (Netbeans Facade-pattern, almost like DAO).
First run worked, but the second run had lost its instance.

So after some masterful reading, googling and swearing I found a soultion, I needed to use the InitailContext and get the @Named bean from there.

yourInstance = InitialContext.doLookup("java:global/YourAPP/YourBean");

And then it was all downhill from there.

I got a lot of experience with Calendar and Date, almost every method in Date is deprecated now, with Calendar as a replacement. So I only use Date as date-instances but for manipulating the date I use Calendar. Go Java 8!


So happy coding! If your having any trouble with a scenario like mine, don't be afraid to ask in the comment-field.

Java EE and Unit testing, Arquillian to the Rescue! Even with Persistence.

As most programmers know, Unit testing is a good practice. You get a quick result if you broke something vital.

And in a simple POJO (Plain Old Java Object) it's not that difficult to make a Unit test, most IDE has JUnit integrated in them.

But what about JavaEE? Now you have a servlet-container, context and persistence to worry about.


There are several solutions for this, the one that I've been focusing on is Arquillian.
Arquillian is a JBoss Community project and development is sponsored by Red Hat, Inc.
http://arquillian.org/

It's a good idé to use Maven with Arquillian. One of the reasons is that you can have different profiles for different servers (glassfish, wildfly, embedded, remote, etc).

My opinions of Maven: http://java-viking.blogspot.com/2014/05/java-ee-maven-and-gradle.html

So Arquillian can simulate JARs or WARs. You can add config-files and classes (or packages).
It can even do persistence.

So i use my Datasource from the server, simulate a War and test it remotely to the server.
The test begins with making a transaction and adding values to the database, I do this with a Facade that Netbeans like to create for JPA Entities.

I've done a test with the findAll-method to see if I get a list with the correct size, and it worked lovely.

So now it's time to test all the important stuff. On my next project I will start with the testing-stuff first now that I know of its capabilities.


So what's next?

Next is to test Arquillian Drone. The Drone-extension is for testing the actual site. So my JSF-sites can actually have automated tests. The newest 2.0.0 (alpha) can even test for mobile.

The Drone can find elements by id and actually do stuff, like login in and testing what the response site is.

So my hours of re-deploying and testing the same thing over and over again feels like a bitter cup of tea right now.

So thats it for now, I have a lot of testing to do. I will also experiment with the managed and embedded server options. But it's always good to have a "remote" server that actually is the same as the release environment,


Comment if you need help with Netbeans, Wildfly and Arquillian, the IDE in the tutorials is Eclipse and uses EclipseLink instead of the Wildfly default (hibernate),

Java EE, Maven and Gradle

So I've been looking a bit at Maven and Gradle.
Gradle is an awesome build tool that have support for the dependencies from maven repositories.

But I have a weak moment, I like the automated stuff in IDEs. And the Gradle-support for Netbeans is not perfect. You can create and open projects, but for a Java EE project, you lose some of the support.

An example is JSF. When you create a normal Web Application in Netbeans, you get automatic support for all the Web technologies it supports. But with Gradle i have to do everything manually.

This is both a good and a bad thing, the good part is to actually learn all the components that are involved, the bad is that it takes time from the coding and frustration while finding the right solution.

Maven, the old and wise, have a different problem. It's problem is that it needs the dependencies declared and downloaded (by maven) while coding.

When you code Java EE against a server, you have the libraries IN the server, the server plugins usually solves this so you don't need to worry about the libraries. They will be provided.
If your using third party libraries, you might need maven? You usually either set the libraries as modules on the server or deploy them separately example Database drivers (JDBC connectors) .


In maven you tell the dependencies to be provided, but you still need them downloaded while coding.
And then comes the kicker, the libraries that the server has, are some times more up to date then those from the maven central repositories!

Even from the same company as the server!

So I'm coding for the Wildfly 8.0 Final, and javax.mail-library isn't in the dependency jboss-javaee-spec. So I had to find it manually and hope that the different version work (1.4.5 in maven, 1.5.1 in wildfly).


So for setting up and starting to code, it's much faster with a IDE and Server-plugin then using Maven.
However!
Maven gives you more structure for different testing and lets face it, many third party libraries are easier to setup via maven. And to automatically do unit-testing in the build face is a plus.

Conclussion:
So I wish that Gradle would be better with Netbeans and I will use Maven for my projects.