4 Replies Latest reply on Aug 22, 2015 2:45 AM by ehugonnet

    Glassfish to Wildfly problems

    Michael Kucinski Newbie

      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?

        • 1. Re: Glassfish to Wildfly problems
          jaikiran pai Master

          Which exact version of WildFly are you using?

           

          Michael Kucinski wrote:

           


           

          • 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.)

          I remember seeing something in the JIRA or WildFly pull requests where this was fixed I think.

           

          • 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.

          ehugonnet might be able to help you on that

           

          As for the Hibernate questions, I don't have much knowledge in that area. Someone from JPA or Hibernate team will be able to help you when they are around.

          • 2. Re: Glassfish to Wildfly problems
            Michael Kucinski Newbie

            Which exact version of WildFly are you using?

            Sorry! I forgot to add that to the original post! 9.0.1.Final.

             

            jaikiran pai wrote:

             

             

            Michael Kucinski wrote:

             

            • Jackson default configuration break our REST services

            I remember seeing something in the JIRA or WildFly pull requests where this was fixed I think.

            Excellent! We try to keep our application as portable as possible, so removing Jackson as a direct dependency would be a massive plus.

            • 3. Re: Glassfish to Wildfly problems
              jaikiran pai Master
              • 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. 

              1. <?xml version="1.0" encoding="UTF-8"?> 
              2. <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"> 
              3.     <persistence-unit name="ProjectPU" transaction-type="JTA"> 
              4.         <provider>org.hibernate.ejb.HibernatePersistence</provider> 
              5.         <jta-data-source>jdbc/ProjectDS</jta-data-source> 
              6.         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> 
              7.         <properties> 
              8.             <property name="hibernate.hbm2ddl.auto" value="update"/> 
              9.             <!--create | update | validate | create-drop--> 
              10.         </properties> 
              11.     </persistence-unit> 
              12. </persistence> 

               

               

               

              I think this is something that you will have to ask in the hibernate dev mailing list. Doesn't "update" work as per your expectations? If not, you'll have to add those details in the thread you create there.

              • 4. Re: Glassfish to Wildfly problems
                ehugonnet Apprentice

                WildFly 9 and 10 work with Netbeans 8.1 Beta 1.

                I've updated the plugin for Netbeans 8.0.2 but as I couldn't have it in Netbeans 8.0.3 (I don't know if that's going to happen) I've released a version for WildFly 9 on my plugin page :

                WildFly Application Server - NetBeans Plugin detail you have to download and install it manually.