Sending an e-mail from the backend application part is a quite common use case in the world of enterprise applications. Although HTML content isn’t standardized message format, numerous mail clients support at least a subset of the markup language. In this post you will learn how to send an e-mail using standard Spring Boot modules and prepare HTML content for a message using Thymeleaf template engine.
In the previous post you could read about separate Spring Boot builds for a local development machine and public environments. It’s highly possible that in addition to such setup you would like to load different Spring properties files based on the active Maven profile. In this note you will learn how to accomplish the desired result in a few easy steps.
The great thing about Spring Boot is no need for an external servlet container. All that is needed reside inside a single runnable JAR file. In a very few steps, development of a new application can be started without installation or configuration of any additional software. Yet, sometimes you might want to deploy your application to some server as a regular WAR file. For instance, you convert an existing application and want to keep your continuous delivery pipe untouched or a particular container is enforced by a company’s policy. The reason for building a WAR file may vary across teams, but for development purpose a simple executable JAR file with an embedded server might be preferable.
SharePoint is widely known among .NET developers, but not so recognized in the group of JVM worshippers. Yet, sometimes integration between these two universes is required and one of possible choices to perform the connection is the set of SOAP web services exposed by the platform. It this article you’ll learn how to communicate your Spring application with a SharePoint instance.
It’s been almost two years since Java 8 was officially released and many excellent articles about new enhancements and related best practices have been written through that time. Surprisingly, one of the more controversial topics amongst all the added features is the Optional class. The type is a container, which can be either empty or contain a non-null value. Such construction reminds the user of an Optional object that the situation when there’s nothing inside must be handled appropriately. Although the definition of the type on Javadoc is quite descriptive, when it comes to identifying valid use cases it’s getting more problematic.
This article has also been published on DZone.
Have you ever been in that conversation in which you had to choose between two or more frameworks/libraries and one of them was so-called JEE standard? Usually a person who advocates for it explains that thanks to standardized API it’s possible to switch the implementation to any vendor whenever needed without a worry that something in our application breaks. In theory, it sounds tempting, but does practice prove it? I’m going to focus on simple case using JAX-RS to verify the assertion.