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.
Redhat
Monitoring the JBoss EAP / Wildfly Application Server with the Command Line Interface (CLI)
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).
Secure JSF Application – why you should always define a servlet mapping
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
Upgrading and patching the Red Hat JBoss Enterprise Application Platform (JBoss EAP)
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.
How to access JSF from an EJB with JBoss Enterprise Application Platform 6 (aka JBoss AS7 / Wildfly)
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.
JGroups & Cloud issues when clustering the EAP 6 – AS 7
As announced this is the last post of our series about clustering of the Redhat EAP 6 and JBoss AS 7. The other posts of this series were
- Clustering in JBoss AS7/EAP 6
- Managing cluster nodes in domain mode of JBoss AS 7 / EAP 6
- Scalable HA Clustering with JBoss AS 7 / EAP 6
- Load-balancing and failover of remote EJB clients in EAP6 and JBoss AS7
- Clustering of the messaging subsystem HornetQ in JBoss AS7 and EAP 6
Overview
This post will dig deeper into the clustering mechanisms of the EAP 6 and JBoss AS 7. We will show different solutions to multicast problems you will get in most cloud networks as well as some other networks. Infinispan uses JGroups to do its cluster communication. Cluster communication here means multiple things: finding other cluster nodes, providing a reliable transfer, implementing multicast communication even if there is no IP multicast available, identifying dead cluster nodes and a little bit more. In fact JGroups is able to do a lot more but Infinispan does not need all of the opportunities JGroups offers. The upcoming HornetQ version 2.3 which will be included in the EAP 6.1 will use JGroups for server discovery too. This post will explain the basic principles of JGroups and how to configure it in different network setups, especially most cloud networks.
Clustering of the messaging subsystem HornetQ in JBoss AS7 and EAP 6
In the recent posts of this series we talked about many different aspects of clustering for the JBoss AS 7 and its quality assured version EAP 6, such as:
- the basic concepts,
- managing cluster nodes in domain mode,
- scalable HA cluster topologies and
- load-balancing and failover of remote EJB clients.
Until now, there is one important thing we have not covered yet: clustering of the messaging subsystem. The EAP 6 as well as the AS 7 uses HornetQ as default messaging provider. In this post we want to give an overview about the clustering abilities of HornetQ and explain how to use the various clustering features in combination with the EAP 6 or respectively the JBoss AS 7. We implemented a simple JMS client application to demonstrate the HornetQ clustering abilities.
Descriptor property substitution in EAP6 and JBoss AS7
Motivation
In a software development process, there are usually multiple environments, such as development, test and production, etc. The development team usually provides the QA users a test version before acceptance and production, as illustrated below.
If, however, the application contains assumptions about the environment, this chain is broken. Therefore it is good practice, for the deployment to make no assumptions about the target environment. A good way to achieve this is that the application servers provide the environment specific configurations of the application, such as datasource configuration or integration of other Enterprise Information Systems (EIS). But this is often not so easy.
Load-balancing and failover of remote EJB clients in EAP6 and JBoss AS7
In the recent posts of this series about the clustering capabilities of the JBoss EAP6 and the AS7, we covered the basic concepts, managing cluster nodes in domain mode and scalable HA cluster topologies. This post will be about clustering capabilities for remote EJB clients. We will explain how to cluster EJB components and invoke them from a standalone remote client with client-side failover and load balancing.
You must be logged in to post a comment.