With more devices connected, the Internet is more and more required resource. Web applications are providing rich content, not only written information. But what if the connection is not available, shouldn't you be possible to access information that was already provided to you? Writing applications that are optimized for offline usage increases user's experience, thus usage of your application.
I've just recently organized a workshop to popularize the Kotlin programming language. I like Kotlin a lot, but I cannot say I mastered it entirely, so this was quite a challenge for me. I like to push my boundaries a bit further every now and then and since presenting in front of group of people is not something that I do every day. I consider this to be the best proof that individual truly understands the topic. And also, knowing something does not necessarily mean one will be good at explaining it.
Common approach on writing modern web applications is to have different technology stack for backend and frontend and let them communicate via RESTful web services. This decoupling, however, may introduce a security issue where attacker uses man-in-middle attack to eavesdrop on communication and inject malicious code. In other words cross-site request forgery. There are multiple ways how to implement protection against these kinds of attacks, like adding hidden input field with CSRF token to every form. But what if we don't generate forms on the server and are rather using stateless REST services?
You have plenty of JVM-based languages to choose from, like Scala, Groovy, Clojure, Ceylon,... and I could go on. There is one another, which just recently hit the major version 1.0.0 and it is Kotlin.
Using Spring's RestTemplate is sometimes more convenient than using JAX-RS implementations. Usually you have Jackson2 on classpath, so JSON to object deserialization is working out of box. But what about parameterized collections like `List
Title can be misleading, but it is the only one thing that annoyed user would search for when trying to figure out this problem.
I know, SOAP-based web services are not cool, but in enterprise world they are still popular since SOAP is well documented and robust and it's been here forever. Recently I have received an assignment to create simple SOAP endpoints. JAVA EE and JAX-WS would be a good choice, but I've decided to stick with Spring WS with Spring Boot as the super-glue.
Recently I have stumbled upon an error when trying to generate JAXB annotated classes using Jaxb2 Maven plugin and XJC goal:
This was a major annoyance at first and couldn't find it anywhere, so when you want to write a SpringJUnit test for let's say Spring controller in Spring Boot similar to this:
This week I've took an OCEJPAD test and passed it with 91%. I would like to add some information about my experience.
Another way how to compose a testable module for OpenEJB embedded container is to use application composer.
When it comes to testing Integration tests are natural way to verify if "everything works together". Integration tests in Java EE environment can be a bit tricky, since for most desired services you'll need an EJB container. There are already several different solutions, among the most popular is Arquillian, popularized by Apache TomEE.
I love playing with new technologies. Especially if they are sweet and simple to use. One of those is definitely jOOQ.
Even though not so popular and hip nowadays, JSF is still a very powerful framework for building web applications. You can do many things using simple code constructs. But sometimes it can be real brain-teaser since there are several ways to achieve one thing. One of those is a problem of navigating across views and passing parameters between them.
In an enterprise application it is a good practice to notify user about long running background tasks. Usual scenarios include filling out some forms and submitting them to server for background computation. While waiting for the result there is a notification displayed about current operation.
This is my first obligatory post, in which I would like to shortly explain why I started this site. I will try to summarize it in three simple points: