-
Notifications
You must be signed in to change notification settings - Fork 127
Rules Difference Between XML based and Java based Rules
As mentioned before, Windup provides a core and a default set of rules to analyze and report on migration of application code. Windup also allows you to write your own custom rules. These rules can be written using either XML or Java. Rules written using XML are referred to as XML-based rules. Rules written using the Java API are referred to as Java-based rule add-ons. Both XML-based and Java-based rule add-ons can be used to inspect (classify) and report on Java source, XML, properties, archives, and other types of files,
XML-based rules provide a quick, simple way to create rules to analyze Java, XML, and properties files. If you simply need to highlight a specific section of Java code or XML file content and provide migration hints for it, creation of XML-based rules is the recommended approach. Creation of custom XML-based rules is covered in this guide.
Java-based rule add-ons provide the ability to create very complex rules, manipulate the shared data model graph, and customize the resulting reports. If you need to test or perform complex conditions and operations or want to manipulate the shared data model graph, create custom reports, or extend the functionality in any other way beyond what the XML-based rules provide, you must create Java-based rules. Creation of custom Java-based rules is covered in the Windup Core Development Guide.
Pros:
-
XML rules are fairly easy to write and require less code.
-
XML rules are not compiled so you do not need to configure Maven to build from source.
-
XML rules are simple to deploy. You simply drop the rule into the appropriate path and Windup automatically scans the new rule.
Cons:
-
XML rules only support a simple subset of conditions and operations.
-
XML rules do not provide for direct custom graph data manipulation that can be used later by other rules or the generation of reports.
-
XML rules do not support the ability to create custom reports.
Pros:
-
Java rule add-ons allow you to write custom conditions and operations and provide a lot of flexibility.
-
Java rule add-ons allow you to access and manipulate the shared data model graph and to customize reports.
-
You can set breakpoints and test Java rule add-ons using a debugger.
-
IDEs provide code completion for the Windup API.
Cons:
-
You must configure Maven to compile Java rule add-ons.
-
Java rule add-ons that are not included in the Windup core code base must be a full Forge add-on.
-
Java rule add-ons require that you write Java code.
-
Writing Java rule add-ons can be complex and require knowledge of Windup internals.
The following is an example of a rule written in XML that classifies Java code:
<?xml version="1.0"?>
<ruleset id="EjbRules"
xmlns="http://windup.jboss.org/schema/jboss-ruleset"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://windup.jboss.org/schema/jboss-ruleset http://windup.jboss.org/schema/jboss-ruleset/windup-jboss-ruleset.xsd">
<rules>
<rule id="EjbRules_1000">
<when>
<javaclass references="javax.persistence.Entity" as="default">
<location>TYPE</location>
</javaclass>
</when>
<perform>
<iteration>
<classification title="JPA Entity" effort="0"/>
</iteration>
</perform>
</rule>
</rules>
</ruleset>The following is an example of a rule written in Java that classifies Java code:
/**
* Scans for classes with EJB related annotations, and adds EJB related metadata for these.
*/
public class DiscoverEjbAnnotationsRuleProvider extends AbstractRuleProvider
{
@Override
public Configuration getConfiguration(GraphContext context) {
return ConfigurationBuilder.begin()
.addRule()
.when(JavaClass.references("javax.ejb.{annotationType}").at(TypeReferenceLocation.ANNOTATION))
.perform(new AbstractIterationOperation<JavaTypeReferenceModel>()
{
public void perform(GraphRewrite event, EvaluationContext context, JavaTypeReferenceModel payload)
{
extractEJBMetadata(event, payload);
};
})
.where("annotationType").matches("Stateless|Stateful")
.withId(ruleIDPrefix + "_StatelessAndStatefulRule")
.addRule()
.when(JavaClass.references("javax.ejb.MessageDriven").at(TypeReferenceLocation.ANNOTATION))
.perform(new AbstractIterationOperation<JavaTypeReferenceModel>() {
@Override
public void perform(GraphRewrite event, EvaluationContext context, JavaTypeReferenceModel payload) {
extractMessageDrivenMetadata(event, payload);
}
})
.withId(ruleIDPrefix + "_MessageDrivenRule")
.addRule()
.when(JavaClass.references("javax.persistence.Entity").at(TypeReferenceLocation.ANNOTATION).as(ENTITY_ANNOTATIONS)
.or(JavaClass.references("javax.persistence.Table").at(TypeReferenceLocation.ANNOTATION).as(TABLE_ANNOTATIONS_LIST)))
.perform(Iteration.over(ENTITY_ANNOTATIONS).perform(new AbstractIterationOperation<JavaTypeReferenceModel>() {
@Override public void perform(GraphRewrite event, EvaluationContext context, JavaTypeReferenceModel payload) {
extractEntityBeanMetadata(event, payload);
}
}).endIteration())
.withId(ruleIDPrefix + "_EntityBeanRule");
}
...
}| Requirement | XML Rule | Java Rule Add-on |
|---|---|---|
Easy to write? |
Yes |
Depends on the complexity of the rule |
Requires that you configure Maven? |
No |
Yes |
Requires that you compile the rule? |
No |
Yes |
Simple deployment? |
Yes |
No |
Supports custom reports? |
No |
Yes |
Ability to create complex conditions and operations? |
No |
Yes |
Ability to directly manipulate the graph data? |
No |
Yes |