Show Table of Contents
16.4. Other Environments
16.4.1. JBoss Modules, WildFly and JBoss EAP
To deploy an Planner web application on WildFly, simply include the optaplanner dependency jars in the
war file's WEB-INF/lib directory (just like any other dependency) as shown in the optaplanner-webexamples-*.war. However, in this approach the war file can easily grow to several MB in size, which is fine for a one-time deployment, but too heavyweight for frequent redeployments (especially over a slow network connection).
The remedy is to use deliver the optaplanner jars in a JBoss module to WildFly and create a skinny war. Let's create an module called org.optaplanner:
- Navigate to the directory
${WILDFLY_HOME}/modules/system/layers/base/. This directory contains the JBoss modules of WildFly. Create directory structureorg/optaplanner/mainfor our new module.- Copy
optaplanner-core-${version}.jarand all its direct and transitive dependency jars into that new directory. Use "mvn dependency:tree" on each optaplanner artifact to discover all dependencies. - Create the file
module.xmlin that new directory. Give it this content:<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.3" name="org.optaplanner"> <resources> ... <resource-root path="kie-api-${version}.jar"/> ... <resource-root path="optaplanner-core-${version}.jar"/> ... <resource-root path="."/> </resources> <dependencies> <module name="javaee.api"/> </dependencies> </module>
- Navigate to the deployed
warfile.- Remove
optaplanner-core-${version}.jarand all its direct and transitive dependency jars from theWEB-INF/libdirectory in thewarfile. - Create the file
jboss-deployment-structure.xmlin theWEB-INF/libdirectory. Give it this content:<?xml version="1.0" encoding="UTF-8" ?> <jboss-deployment-structure> <deployment> <dependencies> <module name="org.optaplanner" export="true"/> </dependencies> </deployment> </jboss-deployment-structure>
Because of JBoss Modules'
ClassLoader magic, you'll likely need to provide the ClassLoader of your classes during the SolverFactory creation, so it can find the classpath resources (such as the solver config, score DRL's and domain classes) in your jars.
16.4.2. OSGi
The
optaplanner-core jar includes OSGi metadata in its MANIFEST.MF file to function properly in an OSGi environment too. Furthermore, the maven artifact drools-karaf-features (which will be renamed to kie-karaf-features) contains a features.xml file that supports the OSGi-feature optaplanner-engine.
Because of the OSGi's
ClassLoader magic, you'll likely need to provide the ClassLoader of your classes during the SolverFactory creation, so it can find the classpath resources (such as the solver config, score DRL's and domain classes) in your jars.
Note
Planner does not require OSGi. It works perfectly fine in a normal Java environment too.
16.4.3. Android
Android is not a complete JVM (because some JDK libraries are missing), but Planner works on Android with easy Java or incremental Java score calculation. The Drools rule engine does not work on Android yet, so Drools score calculation doesn't work on Android and its dependencies need to be excluded.
Workaround to use Planner on Android:
- Add a dependency to the
build.gradlefile in your Android project to excludeorg.droolsandxmlpulldependencies:dependencies { ... compile('org.optaplanner:optaplanner-core:...') { exclude group: 'xmlpull' exclude group: 'org.drools' } ... }

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.