Glassfish to Wildfly problems
Hey guys,
For a few months now, me and my team have been discussing switching over to Wildfly 9.0.1.Final from Glassfish 4.1 due to Oracle dropping support. At this same time, we discovered that Picketlink, our security framework, is also being dropped in favor of Keycloak. So I started the long process of trying to convert our project. At first, everything went smooth. We stick close to the JavaEE Spec and don't refer to any provider specific code. However, we ran into a few issues after the application deployed.
- Jackson default configuration break our REST services
This is one of the problems we faced right off the bat – Jackson, by default is set to fail when un-marshaling a JSON object to a POJO if the JSON contains an unknown property - a property that isn't present in the POJO. On the client side, we use Angular JS, which adds properties to objects for its own internal tracking (such as $$hashkey with ng-repeats.) To fix this, we were required to write our own ContextResolver<ObjectMapper> to configure Jackson for RESTEasy to prevent this exception from being thrown. This breaks the general rule of avoiding provider specific code.
@Provider
@Produces(MediaType.APPLICATION_JSON)
public class JacksonRestProvider implements ContextResolver<ObjectMapper> {
private final ObjectMapper objectMapper;
public JacksonRestProvider() {
super();
ObjectMapper mapper = new ObjectMapper();
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
mapper.setVisibilityChecker(mapper.getSerializationConfig().getDefaultVisibilityChecker()
.withFieldVisibility(JsonAutoDetect.Visibility.ANY)
.withGetterVisibility(JsonAutoDetect.Visibility.NONE)
.withSetterVisibility(JsonAutoDetect.Visibility.NONE)
.withCreatorVisibility(JsonAutoDetect.Visibility.NONE)
.withIsGetterVisibility(JsonAutoDetect.Visibility.NONE));
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
this.objectMapper = mapper;
}
@Override
public ObjectMapper getContext(Class<?> type) {
return objectMapper;
}
}
- Hibernate refuses to update the schema
Our database schema changes during development. We often add entities or update fields. With Eclipselink running under Glassfish, we set the “javax.persistence.schema-generation.database.action” to “create” and our main changes reflected in the database on each deploy without stepping on or removing existing data. We've tried all of the “hibernate.hbm2ddl.auto” options, but none of them recreate this behavior. The only choice is to drop and recreate the schema with each deployment in order to have an updated schema. Repopulating the tables is an annoying process.
<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"> <persistence-unit name="ProjectPU" transaction-type="JTA"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>jdbc/ProjectDS</jta-data-source> <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> <properties> <property name="hibernate.hbm2ddl.auto" value="update"/> <!--create | update | validate | create-drop--> </properties> </persistence-unit> </persistence>
- Hibernate Fails to Create Abstract Entities
This problem is one I'm still working on. Some of our entities, which are marked @MappedSuperclass, are not being created in the database by hibernate. They work in glassfish, but I see no error in the server log in Wildfly on which hibernate is failing to create them. I'll use a finer log level and search some more.
@MappedSuperclass
@XmlAccessorType(XmlAccessType.FIELD)
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class AbstractMessage implements Serializable{
//...fields with annotations, getters, setters
}
- Hibernate's Naming Strategy Caused Problems with JoinColumns
We use JPA annotations like @UniqueConstraint and @JoinColumn in our schema. Both of these annotations require that the final column names are used in their definition opposed to the entity field names. Hibernate's naming strategy broke a fair number of these definitions. Even after reading the Hibernate documentation, it was very unclear what each naming strategy did and how it affected the table and column names. - Poor Netbeans Integration
This one isn't Wildfly's fault, just a feature that I would like to see. There is exists a plugin for Wildfly and Netbeans, but it doesn't work with WF9.1. It can start the server, but it can't run the application nor can it debug.
These are just a few of the issues we found, and I'm sure there could be more as we test the application. Is there any way to avoid including specific implementation details/code? Has anyone else faced these problems before?
