We are back again. The first day as always is some sort of warming up and getting into the flow. This year was special in so far as one os us (roland) gave his first talk at Devoxx. But let’s start with the first talk. Here are our personal reviews for some of the talks we’ve attended with the author of each review is mentioned after the title in parentheses. These reviews covers JEE6 Enterprise applications, Arquillian, Continous Delivery, Spring Data JPA, Jolokia (of course ;-), Scala and Glassfish rolling updates.
# “Building Next-generation Enterprise Applications in Java” by Bert Ertman and Paul Bakker (Jan)
Wow, finally my first Devoxx talk, held by Java champion Bert Ertman and Paul Bakker - I was quite curious what to expect.
After a (not very exciting, but short) introduction into enterprise applications in general (funtional/non-functional requirements, application 5-tier architecture) the session evolved to three hours quite impressive live coding with Java EE6.
The toolbox the speakers had brought with them contained Glassfish 3.1, JBoss AS7, MySql, Maven, JBoss Forge and IntelliJ. Based on this tooling they started building up a web application called Dukes Duct Tape Store (why? answer: because pet stores suck) from scratch.
For the creation (and addition of new technologies later on) of the Java EE6 project they used a quite impressive tool called JBoss Forge. It provides massive command line support for the handling and creation of Java EE related projects. Everyone who knows Spring Roo should know what I’m talking about - JBoss Forge works quite similar.
Using JBoss Forge,
new-project --named ducttape --topLevelPackage ducttape
creates a maven JavaEE project as well as a basic folder structure.
setup faces
makes a JSF-backed web application out of it.
persistence setup --provider HIBERNATE --container CUSTOM_JTA
configures JPA with Hibernate as persistence layer and creates the appropriate persistence.xml.
During the session they used JBoss Forge to configure further stuff like JMS and (very interesting as well) Unit tests with Arquillian. Aquillian is a real breakthrough in JavaEE testing capabilities since it fills a big gap. There was a specific talk about Arquillian, so expect a blog about this technology from Marcel who attended it.
The evolution of the Duck Tape application during the talk contained the following steps - each step was built up/coded and explained live.
What have I learned during this talk? JavaEE6 is a massive move towards a lightweight and easy-to-use technology standard - and a real alternative to our known Spring-stacks at ConSol. At some points, it even scores with built-in features Spring does not provide from scratch (examples: configuration of a scheduled timer by a simple annotation on an EJB method and CDI events).
I recommend this talk to everyone curious about the evolution of the JavaEE standard - it’s worth watching it, although I missed some CDI features like Interceptors and Decorators, guess they did not fit into the time slot anymore. In the end the guys unfortunately lost a lot of sympathy points by doing some stupid Spring/Rod Johnson bashing on their last slide. Guys, remember where JavaEE6 stole lots of its ideas from ?
The Arquillian project by JBoss simplifies in container testing. The presentation covered several examples, starting with simple ones such as how to create JUnit tests which deploy to an embedded or standalone JBoss AS upon execution.
The more complex examples showed running Selenium and how to heavily modify the deployment(such as creating a project subset deployment containing only relevant classes to speed up testing, using ShrinkWrap and how to CID inject mocked components.
A combination of Arquillian and Citrus (end-to-end integration testing) could be interesting, eg using Arquillian to inject mock components or listener hooks and for deployments.
This talk, held by David Farley (author of the book “Continuous Delivery”) covered the basic ideas behind this approach and his experiences collected when applying it at his company LMAX. The only thing I had heard before about Continuous Delivery(CD) was that these guys propagate releasing ever night to production. What? Yes, sounds scary, so I was curious to check out the details.
Basically, CD can be considered as a kind of mindset change in SW development. It is a logical extension of Continuous Integration and drives this approach even further:
This mindset change causes developers and administrators to collaborate much more than before - a reason why CD is a often mentioned approach in the DevOps movement as well.
Of course, this approach must be backed by massive automation and process support - you have to put lots of efforts into your test coverage, testing process as well as build and deployment automation over several test environments(called a build pipeline).
David listed the following basic principles to achieve CD:
Another interesting point was the way they handle branching. They simply DON’T BRANCH! Or at least only if there is really no other option (like a bug in production which has to be hot fixed). They always work on Head and accept the fact that features not fully implemented yet get released into production. They simply add the UI functionality at last or use some feature toggles to deactivate it until it is ready and released.
Wrapping it up, this talk brought some really interesting insights into a complex development scenario where CD is applied successfully. The approach sounds interesting, but my impression was that you have to put very big efforts and money into testing coverage (David talked about ten thousands of acceptance tests which would run 24h if they would be run sequentially) and deployment process. In my opinion, the approach is better suited for product development (where you have ongoing evolvement of the software) than classic projects. How “often” and “easy” do we release CM6, btw? ;)
This short (30min) talk introduced Spring Data JPA - an abstraction layer on top of “classic” JavaEE JPA. You might argue (like I did at first): What, another abstraction layer on top of an abstraction layer?
The reasons presented by Oliver Gierke were quite obvious: even with JPA/Hibernate abstraction, you still have to write boilerplate code (think of each save method calling entityManager.persist(this) in an entity). This is where Spring Data JPA comes to rescue.
I is activated by a single line in your Spring configuration and provides some Spring magic generating the necessary boilerplate code for interfaces annotated with @RepositoryDefinition.
For example, it will build the correct queries by parsing the method names (and traversing keywords) in the annotated repository interface:
List<Account> findByCustomerFirstnameAndCustomerLastName(Customer customer)
generates a database lookup (by using the JPA criteria API) for a customer by first name and last name.
Spring Data JPA provides hooks and integration with other frameworks as well - Oliver showed the integration of another project (queryDSL) providing an optimized and typesafe query API for complex queries (which cannot be autogenerated) by using queryDSL.
The talk was too short (and I was too late and missed the first slides ;) ) to get a deeper impression wether this abstraction layer provides enough value to proclaim its usage (or even the combination with queryDSL - welcome to framework jungle?). But it’s definetely worth a look, especially for projects with a lot of database interaction and thus lots of query methods which might be autogenerated by Spring Data JPA.
# “Jolokia - JMX on Capsaicin” by Roland Huss (roland)
Now for an inverse review ;-). This year I had the chance to present my pet project “Jolokia” at the Devoxx (thanks for the invitation, by the way). I did quite some of preparation for this 30 minutes talks including video recordes rehearsals and so on. This was my first talk in a foreign language although I did a good number of talks in german in the past. Unfortunately at the beginning of the talk there were some technical issues with the beamer and that was not something I was prepared very well for and hence the talks didn’t work as I expected.
There are some points which might be useful if you are going to give a talk on your own at Devoxx sometimes:
At the end, my feelings are a bit mixed. Twitter feedback was good, however the number of attendees was a bit disappointing. Well, the competition on the parallel tracks was really big and if I had to choose I would have chosen a different talk, too. Sonar (which we use intensively for Jolokia), JBoss Forge and hard core JVM GC analysis are all great topics. Bad luck I would say ;-).
Since I now took this first plunge, I hope to get the chance to come back again to Devoxx as speaker since it is really a very intense experience and I know now how to do it better ;-).
My first session in any Devoxx Conference, so the expectations were quite high. The topic was also interesting. The intention was to explain why Scala is better than other languages. In particular ahead of Java (OOP), Groovy (Scripting), Haskell (Functional) on there corresponding areas.
Apart from his English skills the beginning was interesting, key difference between Java and Scala as keep it simple vs do more with less. On a sudden he put the gear and start explaining various features of Scala with out any introduction to the syntax, which was too fast to follow :-( The following topics where covered on the talk
My impression is even though it was marked as for NOVICE, the course was too advanced on level . For some one with out prior knowledge, it was difficult to follow
In the second part, Mario Fusco talked about ‘Agile Scala’. Scala is a human readable way of writing code, which help to make business understandable by reading the code. which uses the type safe patten and it uses less boiler plate code than in Spring. Many DSL examples are found a gist.github.com/1262988.
How introduce scala into an enterprise project? It is better start Scala for writing tests and gradually can also be used in production code. As a fairly complex language, there is a risk of unmaintainable code with Scala. All in all, the talk was very unprepared and no enough meat for a 75 minutes talk. And again low interaction with the audience and very high level.
The last talk of day one - 30minutes about Glassfish application versioning and live updates.
At first, Marian introduced the basic idea of application versioning in Glassfish. An application
can coexist in several versions on one server instance - while only one version is marked as “enabled”, of course.
To deploy a new version of an application, the version ID is simply appended to the application name during deployment:
asadmin deploy --name myApp:v1 ./myApp.war
Having done this, the new version 1 of myApp will be deployed, marked as enabled while
the old version (e.g. version 0) remains on the server as disabled.
Why is this good? Because it provides an easy and fast way for a rollback in case of problems:
asadmin.bat enable myApp:v0
The problem with the above approach is quite obvious: current sessions in v0 will be lost, and during the switch from v0 to v1 no requests will be served. It’s a (tiny) downtime.
After these basics, Marian introduced the rolling-upgrade feature which is planned to be released in Glassfish in the next months. Rolling upgrade shall provide smooth deployments of new application versions while keeping current state and preserving availability.
By using the –rolling-upgrade option during deployment, a RequestsHolder class in Glassfish will kick in and keep all incoming requests during the switch from v0 to v1 and hand them over to v1 after it is successfully deployed:
asadmin.bat deploy --name myApp:v1 --rolling-upgrade ./myApp.war
Sounds good, but what about the sessions on v0? They are lost - unless you provide the keepstate option as well:
asadmin.bat deploy --name myApp:v1 --rolling-upgrade --keepstate ./myApp.war
Now Glassfish backups and keeps all sessions in v0 and recovers them after deployment on v1. The developer is of course responsible of assuring that v1 sessions are backwards compatible in this case.
There is another very interesting option for nightly upgrades, when you assume (or hope) that no users are currently active. You can tell Glassfish to only do the version update when no requests are currently handled:
asadmin.bat deploy --name myApp:v1 \
--rolling-upgrade \
--keepstate \
--when-no-requests \
./myApp.war
What about existing sessions? Ok, let’s make sure there are no sessions as well:
asadmin.bat deploy --name myApp:v1 \
--rolling-upgrade \
--keepstate \
--when-no-requests \
-when-no-sessions \
./myApp.war
Glassfish will now hold the deployment until no sessions are active and no new requests are currently handled. To avoid letting it wait forever, you can specifiy a –cancel-after and/or –force-after option as well.
This is really cool stuff, and as already mentioned, it is planned to be released the next months. In the end, Marian presented a short view into the future - the next stage of application versioning support, currently planned for Glassfish 4.0 (scheduled for end of 2012). Similar to BPM engines, Glassfish will be able to run an application in two different versions simoultaneously. Old sessions will be handled by old version, new sessions by the new one. How cool is that!?
A short talk, packed fully with interesting information, nice one! And, good to know that my favorite application server is evolving more & more. ;)