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
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:
JBoss EAP 7 and ActiveMQ Artemis as connector between temperature and humidity and the application architecture
Most IoT-Applications face similar challenges on its way from sensor to final aggregation in terms of usage and, where applicable relaying of data. In this article, we introduce an architecture based on the new Red Hat JBoss Enterprise Application Platform (JBoss EAP) in Version 7 to outline a IoT application as a showcase.
MQTT has certainly become a standard protocol for IoT and in this context the Internet of Things is integrated via MQTT.
One new major update of JBoss EAP 7 is ActiveMQ Artemis as Messaging Broker with support for MQTT as transport protocol. JBoss EAP 7 is our preferred technology, i.a. for IoT architectures because of its outstanding technological capabilities thus facilitating efficient development of scalable and secure applications.
A combined temperature and humidity sensor, the Bosch XDK, and Harting’s Mica Box are used to supply data. It is the MQTT and the JBoss EAP 7 Middleware that connect and build a bridge between this sensor setup and the rest of the world.
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)
- 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.
A few weeks ago Red Hat release the Red Hat JBoss EAP 6.4.0 Beta1 as tech preview. Featuring many updates, with additional supported and updated database certifications and the EAP 6.4.0 Beta1 including targeted support of Java 8 / JDK 8.
Oracle JDK 8
Oracle Java Platform, Standard Edition 1.8 (JDK 8) has been added to the list of supported configurations.
Support for OpenJDK 8 has been added, but at the moment support is limited to Red Hat Enterprise Linux 6.
Try it today!
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).
Windup is a tool that scans your application for migration relevant items and presents its findings within an html report. It finds a variety of items starting with standard and vendor specific deployment descriptors and ending with the detail of migration relevant method calls (like JNDI lookups or the use of native APIs).
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.
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/.
One of the biggest advantages, besides the support for the Red Hat JBoss Enterprise Middleware are the access to continuous updates and bug fixes. In previous versions, minor patches could not be applied automatically, also updates or bug fixes had to be installed manually, by changing individual configuration files and replacing Java Archives.
Since version 6.2 the Command Line Interface of the JBoss Enterprise Application Platform (EAP) contains a command to apply minor updates and patches without changing individual files manually.
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.