This blog article is part of a “series of blog articles” about common pitfalls using JPA and ways to avoid them. In this article, we describe issues with using null parameter values.
Continue readingJava EE
JPA Pitfalls (2): List or Set Relationship
This blog article is part of a “series of blog articles” about common pitfalls using JPA and ways to avoid them. In this article, we describe the difference between a set or list relationship.
Continue readingJPA Pitfalls (1): Serialized Collection
This blog article is part of a “series of blog articles” about common pitfalls using JPA and ways to avoid them. In this article, we describe, how easily a relation mapped as collection ends up as a blob.
Continue readingJPA Pitfalls – a Series of Serious JPA Obstacles
Most of our Java-based web-applications store their data in a relational database such as Oracle, PostgreSQL, MySQL, MariaDB or MS SQLServer. The standard way to access and modify the data is using an object-relational mapping as specified by the Java Persistence API (JPA). Over the years JPA has become a mature specification and there are a couple of JPA implementations with strong support such as Hibernate, EclipseLink, OpenJPA and DataNucleus. However, day-to-day project experience demonstrates there are number of pitfalls you might run into when using JPA.
To avoid stumbling into the same pitfall again and again, we collected them with their solutions and presented these pairs of problems and solutions. This is a start of a series of blog articles each describing a pitfall and a way to circumvent it.
Measuring the Lightweightness of Go by Looking at a Simple Web Service
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. 🙂
The lightweightness of microservices – Comparing Spring Boot, WildFly Swarm, and Haskell Snap
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.
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
Deployment Overlays: A new feature of the JBoss EAP 6.1
The Java EE platform provides a component-based architecture, which supports modular concepts to develop applications and reuse components in different applications and environments. Dependencies to the application server specific environment can be defined in deployment descriptors, such as ejb-jar.xml for EJB components.
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.
You must be logged in to post a comment.