wildfly

WildFly 8-10 and JBoss EAP 7 verbose HTTP headers

| Immanuel Sims

As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

Continue reading →

Measuring the Lightweightness of Go by Looking at a Simple Web Service

| tnfink

Inspired by my article The lightweightness of microservices – Comparing Spring Boot, WildFly Swarm, and Haskell Snap, a colleague of mine implemented the same Web service using the Go programming language. You can find his code here: Bitbucket-repo. To compare his implementations with the other ones, I integrated it into the main project (GitHub-repo) and measured it. Here are the results. 🙂

Continue reading →

The lightweightness of microservices – Comparing Spring Boot, WildFly Swarm, and Haskell Snap

| tnfink

A microservice is an autonomous sub application for a strictly defined and preferably small domain. An application built from microservices is scalable, resilient, and flexible. At least, if the services and their infrastructure are well designed. One requirement on the used frameworks to achieve scalability and resilience is that they are lightweight. Lightweightness comes in different flavors. Microservices should be stopped and started fastly, and should consume few resources. The development and maintenance of microservices should be easy.

For this reason, in the Java world, Spring Boot is currently recommended as best choice regarding these requirements. Traditional Java EE application servers are too heavyweight, because they are not developed as basis for single services but as platform for running different applications simultaneously. Thus, they must be bloated.

Being a curious person I used some of my spare time in the last Christmas holidays to actually measure the lightweightness. First I chose Spring Boot and WildFly as “competitors”. I added WildFly Swarm which provides similar features as Spring Boot but is based on WildFly. Then looking at the requirements I decided to include a framework with a real small startup time in comparison to Java-based frameworks and chose Snap based an Haskell. For every framework I built a minimal micro service, wrapped it into a Docker container, and measured its weight.

Continue reading →

Getting started with ELK and JBoss EAP6

|

In this post we will describe what is needed to get started with managing your EAP 6 logs with ElasticSearch, Logstash and Kibana. There are several reasons why you would want to collect your logging output in a central place.

  • Aggregate (output from multiple applications / hosts)
  • Correlate events in different systems
  • Analyze (more than grep)
  • Backup
  • Integrate into monitoring
  • Gather statistics

A common solution that supports all this use cases is provided by the ELK stack. It consists of ElasticSearch (ES), Logstash and Kibana. ElasticSearch provides persistence and analytics, Logstash provides the pipeline that brings your Logs into ES and Kibana provides a GUI for querying and dashboards.

Continue reading →

JBoss EAP / Wildfly – Three ways to invoke remote EJBs

| Heinz Wilming

The JBoss EAP / Wildfly application server provides as primary API the EJB client library to invoke remote EJB components. This client library is the implementation of the WildFly application server to invoke EJB components. The lookup of an object, such as a JMS connection factory, from the naming service is with the EJB client library not possible. For this purpose the remote naming implementation can be used. It can handle lookups of objects from the naming service. Both libraries can be used through the InitialContext of the JNDI API.

This post introduces three ways to configure the InitialContext to lookup and invoke EJB components, describes the pro and cons of each approach and introduces a combination of both libraries.

Continue reading →

JBoss EAP / Wildfly Management Interfaces and Clients

| Heinz Wilming

The JBoss EAP / Wildfly provides a powerful concept for management, configuration, and monitoring of the application server itself and its Java EE applications.

In the previous post we focused on some useful runtime metrics, which are of interest when monitoring your application server and applications. This post introduces the management clients provided by the JBoss EAP / Wildfly Application Server to manage and configure server instances.

Continue reading →

Monitoring the JBoss EAP / Wildfly Application Server with the Command Line Interface (CLI)

| Heinz Wilming

The JBoss EAP / Wildfly provides a powerful concept for management, configuration and monitoring of the JBoss Application Server itself and its Java EE Applications. The concept is based on the detyped management API. All management clients of the application server use this detyped management API to interact with the server.

In this post we focus on some useful runtime metrics which are of interest when monitoring your application server and application with the Command Line Interface (CLI).

Continue reading →

Secure JSF Application – why you should always define a servlet mapping

| Heinz Wilming

If you deploy a JSF application in WildFly 8, you can omit to define the JSF serlvet mapping. In this case three default mappings will be active out of the box.

  • <context-root>/faces/*
  • <context-root>/*.jsf
  • <context-root>/*.faces

Tested on WildFly 8.0.0.CR1 and JBoss EAP 6.2.0.GA

This behavior is not mentioned in the JSF 2.1 spec. But it explicitly allows implementations to use proprietary means to invoke the JSF lifecycle.

In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request processing lifecycle, but applications that rely on these mechanisms will not be portable.

This default mapping can be problematic as it provides several path to access resources within your web application. Especially if you use security constraints to protect parts of your application. For instance if you restrict access to <context-root>/secure/* using a security constraint in your web.xml, web resources can still be accessed via <context-root>/faces/.
Continue reading →

How to access JSF from an EJB with JBoss Enterprise Application Platform 6 (aka JBoss AS7 / Wildfly)

| tnfink

The good old JBoss Seam framework introduced the usage of stateful session beans (SFSB) as backing beans for JSF applications. The trick was to bind the lifecycle of a SFSB to a web context, such as the session or the request context. Meanwhile this concept was integrated into the Java EE by the Context and Dependency Injection (CDI) specification. We really like to use SFSB in JSF because it provides a comfortable way to access the logic and persistence layer with an automatic and painless transaction management.

We also like to modularize our applications by separating its different layers into different Maven modules. Thus, usually the web and application logic are bundled as EJB archives, whereas the web pages are stored in a WAR archive. All modules are combined to an application as an EAR archive. In our opinion this approach is more maintainable than to mix everything into one big WAR archive.

Sometimes the web logic has to access JSF classes, i.e. to query the locale used in the current request. To do this with the JBoss EAP 6, a particularity must be taken into account. By default in the EAP6 only WAR archives containing a JSF descriptor have access to the JSF classes, EJB jars do not.

This is due to rules for implicit class loading dependencies which are added automatically by the application server at deployment time. To access JSF classes from an EJB archive, the EJB jar has to state an explicit dependency to the faces module. This is pretty simple, if you know how to do it.

Continue reading →