How to find out which versions of Jersey, Eclipselink and Mojarra are used in Glassfish 4.1?

Almost in all my projects I use JPA, JAX-RS and sometimes JSF.
Glassfish uses Jersey as implementation for JAX-RS, Eclipselink for JPA and Mojarra for JSF. But how to check which version of these modules is integrated in your Glassfish?

The most straightforward way to accomplish it is run simple command for each module:

# check Jersey version
unzip -p jersey-common.jar META-INF/MANIFEST.MF | grep Bundle-Version
# Output example: Bundle-Version: 2.10.4
# check Eclipselink version
unzip -p org.eclipse.persistence.core.jar META-INF/MANIFEST.MF | grep Bundle-Version
# Output example: Bundle-Version: 2.5.2.v20140319-9ad6abd
# check JSF version
unzip -p javax.faces.jar META-INF/MANIFEST.MF | grep Bundle-Version
# Output example: Bundle-Version: 2.2.7
view raw glassfish-deps-versions.sh hosted with ❤ by GitHub

How to configure docker container for Glassfish with mysql connector

I use Docker a lot in continuous integration process. And the most popular application server for my Java EE projects is Glassfish.

To configure a docker container I have to accomplish the following tasks:

  1. Create Dockerfile. Lets create it from officially supported image
  2. Configure JDBC resource.
    Download mysql driver from maven repository and put it into glassfish lib directory.
    Add connection pool and jdbc resource for glassfish into domain.xml

    <jdbc-connection-pool driver-classname="com.mysql.jdbc.Driver" name="AppPool" res-type="java.sql.Driver">
    <property name="password" value="mypass"></property>
    <property name="user" value="myuser"></property>
    <property name="URL" value="jdbc:mysql://db:3306/mydb"></property>
</jdbc-connection-pool>
<jdbc-resource pool-name="AppPool" jndi-name="jdbc/app"></jdbc-resource>
  3. Enable remote administration. You can use asadmin for it BUT the most straightforward way to do it in Dockerfile is replace admin-keyfile. Here is an example for login=admin and password=adminadmin. 
    admin;{SSHA256}PRJlfDsW8LsXLoX3+ljhTtEevEfjP31pLv0lKdWnmemwanhMPfw36w==;asadmin
  4. Application deployment. Just copy your application into autodeploy directory.

So, as the result you will get something like that:

# Glassfish container configured for Blog app
#
# VERSION 0.1
FROM glassfish
MAINTAINER Andrii Grytsyk
RUN apt-get update
RUN curl http://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.34/mysql-connector-java-5.1.34.jar -o glassfish/lib/mysql-connector-java-5.1.34.jar
COPY domain.xml glassfish/domains/domain1/config/domain.xml
COPY admin-keyfile glassfish/domains/domain1/config/admin-keyfile
COPY target/app.war glassfish/domains/domain1/autodeploy/app.war
view raw docker-file-glassfish.sh hosted with ❤ by GitHub

Orphan Removal vs Cascade Delete. Or how to delete related entities.

Lets clarify what is the CascadeType and Orphan Removal to begin with.

Definition according to official documentation 

CascadeType defines the cascade operations that are applied in the cascade element of the relationship annotations.
Example: a line item is part of an order; if the order is deleted, the line item also should be deleted. This is called a cascade delete relationship.

@OneToMany(cascade=REMOVE) 
public Set<LineItems> getLineItems() { return lineItems; }

Orphan Removal – when a target entity in one-to-one or one-to-many relationship is removed from the relationship, it is often desirable to cascade the remove operation to the target entity.
Example: if an order has many line items and one of them is removed from the order, the removed line item is considered an orphan. If orphanRemoval is set to true, the line item entity will be deleted when the line item is removed from the order.

@OneToMany(orphanRemoval="true") 
public Set<LineItems> getLineItems() { return lineItems; }

When to use 

Cascade Delete removes all children when parent is removed.
So, If you delete user entity, JPA deletes all his photos too.

Orphan Removal removes corresponding child when you remove it from the relationships. So, if you delete 1 photo from user.getPhotos() collection, JPA automatically removes that photo from database too.

I prefer use neither Cascade Delete nor Orphan Removal. It is easy to support code with explicit deletion using business logic. Moreover, In real project you will archive entities rather then delete them. It goes without saying, that for some minor entities you can use these JPA’s features 🙂

Default FetchType in JPA

There are the following default strategies for fetching data from database

  • OneToMany: LAZY
  • ManyToMany: LAZY
  • ManyToOne: EAGER
  • OneToOne: EAGER
  • Columns : EAGER

According to https://docs.oracle.com/javaee/7/api/javax/persistence/package-summary.html

Looks like a good common approach – child always knows about parent, but parent doesn’t know about children. Also I prefer use unidirectional relationships to begin with. Try to keep your relations as simple as possible 🙂

And the same approach you can use in REST. Add parent into child’s response by default. It goes without saying, you can always optimize it depending on your application and requirements later.