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.
A few days ago, Red Hat released the major version 7 of the open source Java EE application server, Red Hat JBoss Enterprise Application Platform (JBoss EAP).
Red Hat JBoss Enterprise Application Platform (JBoss EAP) is the supported and quality assured version of the WildFly application server from the JBoss community.
The JBoss EAP 7 is based on the version 10 of the WildFly application server. In 2013 Red Hat renamed the JBoss AS community project to WildFly to avoid confusion with the JBoss brand which referred to several different things at once, the application server, the JBoss Community, and a range of other JBoss Products.
The main improvements and highlights of the JBoss EAP 7 release
This article focuses on the following main improvements and highlights of the new major release of the JBoss EAP 7:
- implementation of the new specifications of the Java Enterprise Edition 7
- enhanced modularity
- management improvements
- component updates
- compatibility and interoperability
Have you ever tried to expose a JAX-WS web service via https in JBoss FUSE? Well I tried to do that recently and ran into issues. I hope this post may help you on that task.
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 POODLE bug (CVE-2014-3566) affects nearly everything and everybody is trying to secure all of their systems. That includes your JBoss servers. Securing your JBoss 4 or 5 has one pitfall, which I am going to explain in this post. Apart from that it’s easy.
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.
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/.