This article is a presentation of a new little framework, I have developed and used on several projects.
The framework is for Spring Framework and requires Java 8.0. The code is on GitHub and downloadable from Bintray or JCenter.
This is a simple example of code to demonstrate how to use the library fakesmtp-junit-runner to write integration tests with mail servers.
The library has been released on GitHub and Maven Central. Continue Reading
Today I was preparing a presentation about Software Code quality for a TechTalk on Thursday. I made a search on Internet about Automatic Unit test generator and Data Generators. I will present some tools I have tried. Today, we will speak of Randoop.
The first tool name is Randoop.. This tool is existing since 2007 and its purpose is to generate automatically unit tests 🙂 Directly from your class definition!
To use it you have two choices:
To explain short the theory, thanks to the Java reflection it’s quite easy to produce automatic tests validating some contracts of your API.
Some examples: – toString() should never returns null or throws an Exception – equals() and compareTo() methods have a long list of constraints – Reflexivity: o.equals(o) == true – Symmetry: o1.equals(o2) == o2.equals(o1) – Transitivity: o1.equals(o2) && o2.equals(o3) ⇒ o1.equals(o3) – Equals to null: o.equals(null) == false – It does not throw an exception
Therefore this tool is generating unit tests with JUnit(TestSuite) for the list of classes you provide.
I have done some tests and you can reach 50-60% of coverage quite easily.
The main drawbacks of the solution are: – The unit tests are drawing a snapshot (precise picture) of your code and its behaviour however some tests are really non-sense and you don’t want to edit them. – They don’t replace handwritten tests since the tool is not understand the different between a String parameter emailand fullName. He will mostly use dumb strings.
About the technology, it’s not production ready: – I had troubles with the jar and its dependency plume. – The JAR is a fatjar and coming with dependencies that broke my software.
In conclusion, I will fork the software and try to fix the problems to make it more popular 🙂
This article contains few hints when you are using docker. My main article about Docker is How Docker is disrupting Legacy IT Companies.
A presentation I made (in french) about how to modularize C/C++ Softwares and the various ways to implement it.
Today, I released a new library to help developers to write integration tests with mail servers.
The library has been released on GitHub and Maven Central.
Links : github.
Important : Part of the source code of this library has been modified and adapted from the project of FakeSmtp. I want to thank him since his project inspired me the creation of that library.
This library is an extension to JUnit to allow developers to write integration tests where a SMTP server is required.
The how-to is quite simple :
The project requires JUnit 4.11 or higher. It also requires SLF4J API presents in the classpath. I did not bundle them in the library to avoid conflicts.
To use it, adds the library to your maven or gradle config script :
For maven :
<dependency>
<groupId>com.github.sleroy</groupId>
<artifactId>fakesmtp-junit-runner</artifactId>
<version>0.1.1</version>
<scope>test</scope>
</dependency>For gradle :
testCompile "com.github.sleroy:fakesmtp-junit-runner:0.1.1"Step 1 :
Creates a JUnit test :
public class SmtpSendingClassTest {
@Test
public void testCase1() {
}
}Step 2 :
Adds the new Junit rule with its configuration :
public class SmtpSendingClassTest {
@Rule
public FakeSmtpRule smtpServer = new FakeSmtpRule(ServerConfiguration.create().port(2525).charset("UTF-8"));
@Test
public void testCase1() {
}
}Step 3 :
You are ready to use it, controls the mailbox or the server state :
Assert.assertTrue(smtpServer.isRunning());public class SmtpSendingClassTest {
@Rule
public FakeSmtpRule smtpServer = new FakeSmtpRule(ServerConfiguration.create().port(2525).charset("UTF-8"));
@Test
public void testCase1() {
Assert.assertTrue(smtpServer.isRunning());
Assert.assertTrue(smtpServer.mailbox().isEmpty());
}
}
I have tried Vue.js and just love it.
Some weeks ago, I started a new project for which, I have to build an internet website.
After spending really long hours on internet, browsing, collecting every possible testimonials and advices and comparing them to my first impressions, I decided to start with an hybrid / multiple page site.
(if you are interested by the reasons, it will be the subject of another post).
An hybrid /multiple page site is a website where the content is rendered both from server side and client side at the opposition of single page application (SPA) full client side and a classical server side site(PHP..) Since I want to use the power of modern Js Frameworks as double binding, refreshing, Ajax widgets, Es2016, reactive programming and somewhat control which pages needs to be reloaded, I had to make a choice.
The list of choice is somewhat limited if keep only the 5 most popular ones. (yes I am resolutely not a pioneer of the JavaScript Jungle)
I made the following list :
I defined some selection criteria besides the popularity :
No code bloat : specifically to JavaScript, the syntax and the missing OOP native programming have been producing many frameworks with dumb syntax without any semantical and often syntaxical meaning. To overcome the limitations, many frameworks are using syntax sugar, making them a nightmare to memorize. The most ridiculous is the attempt to stick on these syntaxical blobs, some pseudo theorical terms.
A good framework should offer different levels of usages from the straightforward approach to build quickly and easily a website with the common use cases to the low-level approach where the experimented developer is able to tune the required details. What has been done in Laravel, Spring framework or Symphony are good samples.
Symphony framework is known as a huge galaxy. Many components, industry quality grade, but an overwhelming complexity if you start head on.
Therefore they have created a micro — framework called Silex to bootstrap an PHP application without the nasty details and it is deadly simple. If you want more complex things, the components behind Silex are the Symphony ones.
For a web framework, always study how do they handle forms. Especially a basic post form. It takes five minutes in plain HTML to build an (unsecured) form. How long does it take with this framework?
The same thing works for **Spring* and Spring boot.
The framework must have a business friendly licence. No doubt, no legal restriction for the future company. (by the way do you know you cannot build weapons software in Java, please stick to the line…)
An extensible / plug-ins architecture. I believe the success of a framework resides in the possibility to enable the necessary functionalities (aka feature toggling) during your project. Authentication, reactive programming, lazy loading, modularity.
Based on these selection criteria, here is my evaluation.
Disclaimer: I have a highly respect for the guys who wrote these frameworks and I do not doubt of their outstanding skills. AngularJS
I have experienced projects with AngularJS and I renounced since it is a deprecated technology. Too much code bloat, slow (I should rather say hard-to-tune) and all efforts are concentrated on the new Angular framework. Also, I think I could have a problem with my use case and disabling the AngularJS router.
Angular 2: I have received a training in January and wrote several prototypes since. I have been a huge fan of typescript, angular-cli. I was happy and thinking, they took the best ideas from the other frameworks and build a big melting pot.
Angular : melting pot
In Angular, you will find web components, uses template a la React.js, you have opt-in double binding, directives, modular architecture, lazy loading and so on and so on. But I progressively hate Angular for many details, slowing me down in my developments.
I really dislike their API and concepts to build forms. You have two choices, a template form design and programmatic form design. The first one is almost useless and the second one is deadly cumbersome.
In Angular, they decided to kill HTML and recreate it. How? Case-sensitive attributes and non HTML attributes. You cannot use your normal code editor on it. Beautifier tools not works or partially works. And worse of all, they conceive this awful syntax based on brackets, parens, Well, I think their are huge practitioners of the Brainfuck language.
Brainfuck language
The last issue I encountered is with their wish to produce an industrial, scalable (in the sense if I put more developers on my project, I maintain a stable learning and complexity curve). Yes, they provide dependency injection, IOC. But it really increases the learning curve.
I really wanted to start with React.js. As far I have studied it, the framework seems full of promises, with some nice pluggable functionalities.
However at the time I began to use it, I received a lot of news. The concern is about the React.js license, the Facebook license (link1, link2, link3).
Since there is a threat for the future business (everything can be considered as a social network after all), I have rejected it.
I have never tried Ember.js. Based in my readings, the framework is definitely worth of attention to build SPA applications but not for my use case. Note : during the writing of this post, I felt on that link, confirming that maybe I was wrong about ember.js
On Twitter, I am receiving a lot of feedback from happy users of Vue.js and I decided to give a try.
The syntax seems deadly simple.
Here is the brief of my experience :
I did not use vue-cli, I had to create my own packaging to adapt Vue.js to multipage architecture.
Code bloat: the Vue.js framework is really simple and the documentation quite good. The documentation for the plug-in vue-loader is quite good but I really hate the webpack syntax to enable it (rant..)
Learning curve: I did not try the most hard-core functionalities of Vue.js, though I am using vue-loader, a different template renderer (pug), transitions, a little bit components and lazy loading.
My biggest difficulty have been to maintain my js bundle as low as possible by producing chunks.
The second issue has been to understand why creating a view was creating an App and my component below using the render() function. However I think that Vue.js is easier than Angular. 2.
As in the previous example, the syntax is quite straightforward, no need to learn complex concepts to begin with.
The framework is also compatible with Typescript and the logic behind is quite simple.
Vue.js can be extended with several plug-ins and functionalities. I did not try all of them and the fact you are enabling them manually is comforting me in my approach.
Vue.js is not enforcing a particular programming paradigm(IOC, interfaces, Reactive programming, or. RxJS).
The only reproach I could formulate is a little fear about the Vue.js ecosystem. Please integrate existing libraries rather trying to recreate or mimic ReactJS libraries.
In conclusion, both of these frameworks are legitimate and have their lot of practitioners, and I don’t blame it. Vue.js has been my choice and I do not regret it, yet, since it has made my project easy, fun and effective.
I will try to provide more feedback in the following weeks especially on form editing, unkt testing and E2E testing.
Thanks for your attention
This article is part of my working notes on the subject of "How to migrate Web applications running on JBoss AS 5 to the version 7".
I will go straight to the details though here is some lines about JBoss Server.
From Wikipedia : JBoss Application Server(Now called Wildfly) is an application server authored by JBoss, now developed by Red Hat. WildFly is written in Java, and implements the Java Platform, Enterprise Edition (Java EE) specification. It runs on multiple platforms.
On 20 November 2014, JBoss Application Server was renamed Wildfly.
The product history according Wikipedia is :
The JBoss AS community project has been renamed to the WildFly community project wildfly.org
According this JBoss 5 to 7 in 11 steps, the benefits are :
Processing time decreased by 25% without any code change. Development speed increased in my opinion (it is really hard to measure it) by 50% and we are much more productive (faster server restarts). Memory footprint lowered from 1GB to 512MB. Finally automatic application redeployment finally works! However there is always a price to pay – the migration took us 4 weeks (2 sprints).
Thanks to the presentation from Roberto Cortez, we have a clear picture of the migration.
JBOSS 5 Architecture
JBOSS 7 Architecture
When the PAAS or the Web application server have to be upgraded, several regressions may happen. The team has to pay attention to :
Server functionalities and integration : between the versions, some functionalities and integrations provided by the server may have evolved, be fixed or simply disappeared.
Server configuration : The way the server has been configured, using scripts, GUI, may have changed, forcing the team to change their configuration files and finding the corresponding new way of doing it.
Server deployment configuration : Your deployment model configuration may have to be upgraded : single node, clustered mode, disaster recovery, high availability, reverse-proxying may behave differently in the new versions.
Application deployment configuration : the way to deploy your web applications may have changed in the new versions (GUI mode to script mode…)
Server API Regressions : usually Web Application servers are implementing a specific JEE API version, Servlet API and so on. These API may have changed causing regressions in your applications.
Application regressions : JBoss is including many components extending the JEE with BPM, Persistence, implementation. It is really important to track your dependencies (using Tattletale or mvn dependencies:tree) and interview your team about possible hacks and fixes to overcome the limits of JEE 5. This kind of workaround is difficult to migrate.
Training and risk management : This kind of migration contains its part of risks and changes. Both can create frictions inside your team of between the IT Team and your Dev teams. To ease the migration, don’t forget to dedicate some time to your teams into training to learn the new features of JAS 7. You will also have to adapt your project management to freeze for a while the features until the migration has been done.
This section is providing a checklist to help developers and managers to evaluate the migration risk of their applications.
Here is a list of common issues during the migration of applications with JBOSS AS.
4.2. Debug Migration Issues 4.2.1. Debug and Resolve Migration Issues 4.2.2. Debug and Resolve ClassNotFoundExceptions and NoClassDefFoundErrors 4.2.3. Find the JBoss Module Dependency 4.2.4. Find the JAR in the Previous Install 4.2.5. Debug and Resolve ClassCastExceptions 4.2.6. Debug and Resolve DuplicateServiceExceptions 4.2.7. Debug and Resolve JBoss Seam Debug Page Errors
There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We’re now at the point when we have quite a patch set of features backported from WildFly to AS 7.
JMS : JBoss Messaging server has been deprecated and the compatibility with a JBOSS AS 5 server is really tough to maintain. Some solutions exists as explained below in the article.
Here is a summary of the evolutions between the JBoss AS version 5 and the version 6.
Here is the compiled list of modifications including the minor version fixes.
In JBoss Enterprise Application Platform 5, the class loading architecture was hierarchical. In JBoss Enterprise Application Platform 6, class loading is based on JBoss Modules. This offers true application isolation, hides server implementation classes, and only loads the classes your application needs. Class loading is concurrent for better performance. Applications written for JBoss Enterprise Application Platform 5 must be modified to specify module dependencies and in some cases, repackage archives.
[Server functionality, Server deployment configuration] Domain Management : In JBoss Enterprise Application Platform 6, the server can be run as a standalone server or in a managed domain.
[Application Deployment] Deployment Configuration : Standalone Servers and Managed Domains : Boss Enterprise Application Platform 5 used profile based deployment configuration. These profiles were located in the EAP_HOME/server/ directory. Applications often contained multiple configuration files for security, database, resource adapter, and other configurations. In JBoss Enterprise Application Platform 6, deployment configuration is done using one file. JBoss Enterprise Application Platform 5 configuration files must be migrated to the new single configuration file.
[Server functionality, Application deployment configuration] Ordering of deployments : Application Platform 5 applications that consist of multiple modules deployed as EARs and use legacy JNDI lookups instead of CDI injection or resource-ref entries may require configuration changes.
[Server functionality, Application deployment configuration] Directory Structure and Scripts : As previously mentioned, JBoss Enterprise Application Platform 6 no longer uses profile based deployment configuration, so there is no EAP_HOME/server/ directory.
[Server application, Application deployment configuration, Application regression JNDI Lookups JBoss Enterprise Application Platform 6 now uses standardized portable JNDI namespaces.
[Server functionality, Server configuration, Application configuration, Application code] : Changing logging dependencies
[Server API, Application configuration regressions] Resource adapter configuration : In previous versions of the application server, the resource adapter configuration was defined in a file with a suffix of *-ds.xml. In JBoss Enterprise Application Platform 6, a resource adapter is configured in the server configuration file.
[Server libraries] Technologies upgrade : JDK 6, JSF 2, Bean Validation (JSR-303), CDI, EJB 3 (1.1.13)
VFS Library update
[Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS
[Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.
Here is the compiled list of modifications including the minor version fixes.
Unlike previous releases, with AS 7.1, remote access requires secure authentication by default. This includes both managment (native, jmx, etc) and various remote application protocols (ejb, jndi, jms, etc); Added SSL support for the Remoting interfaces.
[Application configuration deployment] Management API improvements : All configuration attributes are updatable via the CLI. Direct edits to the XML are not necessary.
[Server functionality] Various Administration Console Improvements and Management changes
[Server API] Remote Connectivity Added support for remote EJB, JNDI and JMX invocation over JBoss Remoting 3, IIOP, Remote JMS. Three modes for accessing remote EE components using JNDI (Client, Traditional Remote, and Delegated).
[Server deployment model] Clustering Enhancements : Standalone Servers and Managed Domains : Numerours fixes in HTTP Session Replication, Clustered Web SSO, EJB Stateful Session Bean Replication, EJB load-balancing and failove, JPA XPC propagation
[Server functionality] CLI Regressions jboss-admin.sh renamed to jboss-cli.sh, data-source add" "--pool-name" argument seems to have changed to "–name".
[Server libraries] Technologies upgrade :
Upgrade Google Guava to 11.0.2
[Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS
[Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.
[Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS
[Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.
According link, we thought it would be really hard to connect with JMS server based on JBoss 5. It turned out that you have 2 options and both work fine:
Repackaging Dependencies and fix the EAR Layout: link
Install and configure the JDBC Driver link
Update the Resource Adapter Configuration
Configure the datasource for Hibernate and JPA : If your application uses JPA and currently bundles the Hibernate JARs, you may want to use the Hibernate that is included with JBoss Enterprise Application Platform 6.
In WildFly 8, a resource adapter is configured in the server configuration file. If you are running in domain mode, the configuration file is the domain/configuration/domain.xml file. If you are running in standalone mode, you will configure the resource adapter in the standalone/configuration/standalone.xml file.
More details there How to migrate from AS5 or AS6 to Wildfly
Here is the list of tasks implying some rewriting inside your application code.
Migration JEE 5 to JEE 6
Upgrade to JPA 2.0
Update your SOAP Implementations using JBossWS-CXF
Upgrade Hibernate from 3 to 4
Replacing JBOSS Cache by Infinispan Cache
Configure JAX-RS / Resteasy changes
Fix Hibernate’s sequencer
Replace JBOSS AOP Interceptors : JBoss AOP was used by the EJB container. However, in AS 7, the EJB container uses a new mechanism. If your application uses JBoss AOP, you need modify your application code as follows.
Migrating JNDI : Migrating JNDI namespaces
Update the datasources : link
Rewriting of your RMI Code : oss 5 and 7 are totally different and this kind of communication will not work.
Using CDI instead of plain old Singletons
Here is a list of useful tools to assist you in your migration.
IronJacamar : to update your datasource configuration
Tattletale : to find the application dependencies
Gilder : An application for migrating the configuration of JBoss AS 5-based servers to JBoss AS 7-based servers.
Tools and tooling to migrate to JBOSSS 6 : Link
Upgrades to newer versions of WildFly or JBoss EAP may be handled using the JBoss Windup migration tool. JBoss Windup migration tool
In this short story, I will relate how I migrate my blog personal website from a classic VM instance to a container using Google Cloud Container Engine and Kubernetes, Docker, Nginx.