View source | View content page | Page history | Printable version   

Projects:WildFly Support/Specs

Functional Requirements

The only functional requirement is to be able to deploy Openbravo on WildFly application server.

Technical Requirements

The requirements consist in the list of problems found while trying to deploy Openbravo.

Issue Severity Description Solution Status
Incorrect Servlet definitions critical In web.xml there are several classes marked as servlet but they do not implement Servlet interface. This prevents WildFly to start. There are two cases:
  • Incorrectly defined elements: they should be cleaned up
  • Standard UI processes (AD_Process) incorrectly generate Servlet definition in web.xml:
    • Prevent this to occur even with current definition
    • Fix defintion of existent ones in core
    • Set proper default for new cases
Weld clashes critical WildFly implements Java EE 7 specifications which includes CDI (JSR-346). CDI, in the same manner than in standard Openbravo, is implemented by Weld being it part of the core WildFly's infrastructure. Standard Openbravo, in order to be able to be deployed in non Java EE application servers, such as Tomcat, includes Weld libraries and dependencies. If these libraries are deployed in WildFly, there are clashes (due to different versions) that prevent the server to boot the application. A new property application.server can be added to, then its value is wildfly (note case sensitive lower case), Weld libraries will not be copied to Web App Libraries directory, being possible in this manner to use WildFly's defaults. done
Weld Listener major In order to be able to make use of CDI in non Java EE servers, it is necessary to add org.jboss.weld.environment.servlet.Listener as a listener, so Openbravo defines a mapping for it that is included in web.xml. This is not required for WildFly, and in case it is present, a ClassNotFoundException is thrown on startup. If application.server property is set to wildfly, generated web.xml does not include this listener. done
Some incorrect generated URLs minor Some URLs (ie. Openbravo logo) are incorrectly generated because context path is different in

WildFly than in tomcat: in tomcat it ends with / and in WildFly it does not. This issue prevented Openbravo logo to be displayed.

Enforce context path to end with / so no other change is required in any place this assumption is done. done
Incorrect Manifest minor Default MANIFEST.MF cannot be read. This is only a problem when deploying from sources within Eclipse, on the other hand, deploying through a war file, does not raises this problem because a different manifest is generated. Fix it done

Known Limitations

Rebuilding Openbravo from MMC after installing/updating modules is only allowed in Tomcat. When working in WildFly command line rebuild and restart will be required.

Retrieved from ""

This page has been accessed 924 times. This page was last modified on 8 September 2016, at 10:29. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.