Uploaded image for project: 'WINDUP - Red Hat Application Migration Toolkit'
  1. WINDUP - Red Hat Application Migration Toolkit
  2. WINDUP-520

Rule Externalization - Introduce a Rule, RuleProvider and RulesetMetadata API

    XMLWordPrintable

Details

    • Story
    • Resolution: Done
    • Major
    • 2.2.0.Final
    • 2.1.0.Final
    • None

    Description

      We need an API to store the following Metadata.

      <ruleset id=”WLS_10_12_TO_EAP_6” phase=”...”>
      <metadata>
      	<dependencies>
      		<addon id=”org.jboss.windup.rules:windup-rules-javaee:2.0.1.Final”>			<addon id=”org.jboss.windup.rules:windup-rules-java:2.0.0.Final”>
      		<!-- Do we need a specific version? Perhaps minimal?
                                     What if an old rule runs in new windup which needs newer addon? etc.-->
      	</dependencies>
      
      	<sourcePlatform id=”weblogic” versionRange=”(10,12]”/>
      	<sourceFramework id=”ejb2”/>
      	<targetPlatform id=”eap6”/>
      	<targetFramework id=”ejb2”/>
      	<targetFramework id=”ejb3”/>
      	<tags>
      		<tag>require-stateless</tag>
      		<tag>require-nofilesystem-io</tag>
      	</tags>
      	<executeAfter></executeAfter>
      	<executeBefore></executeBefore>
      </metadata>
      </ruleset>
      

      Currently we use Context hashmap to store the metadata.

      We started using metadata for more that what Context was initially intended for, and storing to hashmap is becoming cumbersome and impractical (needs type checks and type casts; the map can store anything without type safety / validation).

      For example:

      If we have "tags" as a set of strings, but want to allow the user to pass a single string, or an array of strings, or a collection of strings, we need to do this:

          private static void normalizeRuleMetadata(Rule rule)
          {
              if (!(rule instanceof Context))
                  return;
      
              Context ctx = (Context) rule;
              Object category = ctx.get(RuleMetadata.CATEGORY);
      
              if (category == null)
              {
                  ctx.put(RuleMetadata.CATEGORY, new HashSet());
                  return;
              }
      
              if (category instanceof String)
                  category = ((String)category).split(WindupRuleProviderBuilder.TAGS_SPLIT_PATTERN);
      
              if (category instanceof String[])
                  category = Arrays.asList((String[]) category);
      
              if (category instanceof Collection && !(category instanceof Set))
              {
                  HashSet categoriesSet = new HashSet();
                  for (Object catItem : (Collection) category)
                      if (!(catItem instanceof String))
                          throw new WindupException("Rule categories may only contain strings, but contains: " + catItem.getClass().getSimpleName());
                      else if ("".equals(catItem))
                          continue;
                      else
                          categoriesSet.add(((String)catItem).trim());
                  ctx.put(RuleMetadata.CATEGORY, categoriesSet);
              }
      

      The proper way (IMO) is to have several overloaded Java methods in the metadata API, which would do this in the right place, not based on type checks ex-post. More - the ex-post solution is forcing duplication and is error prone, because between calling such "normalizing" method and the origination of metadata, other code may tamper these data and either needs to duplicate those checks, or may forget them and fail on ClassCastException.

      We should introduce a type-safe API which would allow the rule structures (Rule, RuleProvider, Ruleset) to have their metadata.

      Lower level elements could query the parent elements for defaults or merge it's values with these, as appropriate for individual metadata types.

      Attachments

        Issue Links

          Activity

            People

              lincolnthree Lincoln Baxter III (Inactive)
              ozizka_jira Ondrej Zizka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: