[
https://jira.jboss.org/jira/browse/JBRULES-1945?page=com.atlassian.jira.p...
]
Shahad Ahmed commented on JBRULES-1945:
---------------------------------------
I've created a patch (attachment ruleflow_migratory.zip) that adds more support for
migrating drools version 4 ruleflows to drools version 5, including full support in the
Guvnor and Eclipse plugin as well! The patch also fixes a number of bugs in the existing
ruleflow support.
The existing support for version 4 ruleflows allows .rfm (i.e. non-graphical) ruleflow
files to be compiled if the drools.ruleflow.port property is set. The following patch
extends support for ruleflow migration into the Guvnor and Eclipse Plugin to allow
graphical ruleflows (.rf files) to be migrated and viewed.
I've detailed the headline enhancement/fixes immediately below, and there's a full
list of all the file changes, with more details of the modifications further below. I hope
this will allows existing version 4 users a more seamless upgrade path to drools 5 from
their existing drools 4 packages that use ruleflows.
Headline Fixes/Modifications
-----------------------------------
The patch adds the following enhancements and bug fixes:
1. Improves the current XSL transformation of version 4 .rfm ruleflow files to also
migrate import and global definition in split, join nodes etc into the header tag of the
version 5 ruleflow. Also migrates the ruleflow version attribute.
2. Fixes bug in the existing ruleflow migration in the compiler where existing version 5
ruleflows will not be added to a compilation package if the drools.ruleflow.port property
is set to allow migration.
3. Allows drools version 4 .rf (graphical) ruleflow files to be opened and viewed as
graphical ruleflows in the drools version 5 Eclipse plugin! The graphical ruleflow is
migrated from version 4 to 5 (bendpoint and all), with a dialog telling the user that the
transformation has occurred but not saved, so the user can back out.
4. Enhanced Guvnor to migrate existing drools v4 .rfm (non graphical) ruleflow assets to
drools 5 ruleflow assets and allow them to be opened in the Guvnor! The migration only
occurs if the drools.ruleflow.port property is set (as a VM argument , in the case of the
Guvnor).
5. Fixes bug were drools 4 ruleflow assets in an existing repository cannot be opened in
the Guvnor when a repository is "Auto" migrated from v4 to 5. Nor can you
perform any operations on these assets like archive, save etc as a NullPointerException is
thrown on the server. They are effectively stuck in their repository packages - this bug
has been fixed in the patch
Detailed Description of New/Modified Files and Changes
-----------------------------------------------------------------------
There are 10 files in the patch with 7 modifications of existing files and 3 new files.
The patch is attached as a zip that unzips with a directory structure equivalent to the
trunk, but only contains the 10 files. The modified/new files are listed below together
with a summary of the changes. Where possible, I have added a comment with the text "
Migrate v4 ruleflows to v5" near any changes in existing files.
COMPILER
1. drools-compiler\src\main\java\org\drools\xml\processes\RuleFlowMigrator.java
NEW utility class that contains all the methods required to transform drools 4 .rf and
.rfm ruleflow xml format to drools 5 .rf format. This class copies and extends the
original methods in ProcessBuilder that migrated version 4 .rfm files to version 5 during
a rules compilation. I decided to create this separate utility class, as the Eclipse
plugin and the Guvnor will also access the methods here.
This class also has a simple main class that allows it to transform version 4 .rf files in
case anyone want to use it stand alone via the command line.
BUG FIX: Note this class also fixes a bug I found in the original ruleflow migration code
in portToCurrentVersion in ProcessBuilder. The original code read the input Reader
parameter to create a string version of its xml contents using the convertReaderToString
method. If the xml was found to be already a version 5 ruleflow then the original Reader
object was returned as the result with the intention that the ruleflow and hence the
original Reader were not modified - however the act of reading the Reader means that it
content will have been exhausted and any subsequent use of this allegedly
"unmodified" reader will return no content. This bug manifests if you set the
drools.ruleflow.port property true to allow the compiler to migrate v4 ruleflows, and you
try and compile a package containing a version 5 ruleflow - the version 5 ruleflow is
essentially treated as an empty file as the contents of its Reader have already been
read.
2. drools-compiler\src\main\java\org\drools\compiler\ProcessBuilder.java
MODIFIED portToCurrentVersion method to allow the use of both version 4.rfm and .rf
ruleflows files as part of a package. As before, migration only occurs if the system
property drools.ruleflow.port is true. The class has also been re-factored to use the
migration methods/classes from RuleFlowMigrator, and duplicate code in this class has been
removed.
3.
drools-compiler\src\main\resources\org\drools\xml\processes\RuleFlowGraphicalFrom4To5.xsl
NEW file containing an XSL definition that migrates drools 4 .rf (graphical ruleflow) xml
files to version 5. The migration preserves all node positions and bendpoints, imports,
globals etc.
4. drools-compiler\src\main\resources\org\drools\xml\processes\RuleFlowFrom4To5.xsl
MODIFIED to also migrate import and global definitions that might be declared inside
split, join and other nodes. Also migrates the ruleflow version attribute as well now.
Recall this XSL only migrates .rfm (non-graphical) rulefule xml.
GUVNOR
5.
drools-guvnor\src\main\java\org\drools\guvnor\server\repository\BRMSRepositoryConfiguration.java
MODIFIED the create method to perform a full migration of all version 4 Ruleflow assets in
the repository using the methods in Migrate Repository. Migration only occurs if
drools.ruleflow.port system property is true.
6. drools-guvnor\src\main\java\org\drools\guvnor\server\repository\MigrateRepository.java
NEW utility class that migrates all the version 4 .rfm (and .rf) ruleflow assets in a
Guvnor repository to version 5 .rf ruleflow. Previously if you imported, or already had
existing version 4 ruleflow assets into the Guvnor, you would not be able to open them.
Also, any attempted operations on the assets (e.g. archive, save etc) resulted in a
NullPointerException on the server.
When a ruleflow asset is migrated, it is checked-in as a new version of the existing
asset, with a description that it has been auto-migrated from drools 4 to 5 by the admin
user.
Note that although the .rfm (non graphical) ruleflows are migrated to version 5, the
version 5 ruleflow will have no coordinates for nodes on the flow (i.e. no layout info, as
v4 .rfm files did not have any), so when you open the flow, all the nodes are on top of
each other - but at least you can open it now. I did consider using the vertical ruleflow
layout code in the eclipse plugin to add layout details, but that would involve adding
some eclipse libraries to the Guvnor, so I left that as a fairly straightforward
enhancement for the future by using the code in the VerticalAutoLayoutAction class in the
Guvnor - users can always export the migrated .rf and import it into Eclipse, apply the
auto-layout and import it back into the Guvnor as well.
7. drools-guvnor\src\main\java\org\drools\guvnor\server\files\FileManagerUtils.java
MODIFIED importRulesRepository and importPackageToRepository to migrate the ruleflows in
any imported repository or package
8.
drools-guvnor\src\main\java\org\drools\guvnor\server\contenthandler\RuleFlowHandler.java
BUG FIX by adding some null value checks in storeAssetContent. Before this fix, any
attempt to move, save etc on a drools 4 ruleflow asset in a migrated repository caused a
NullPointerException on the server. This Fix along with the fix in
RuleFlowContentModelBuilder.java below fixes this issue. Note that there are also small
changes in storeAssetContent and retreiveAssetContent that leave the old drools 4 .rfm
asset in the repository if it cannot be migrated for any reason - this way at least the
existing package can still be built (assuming the drools.ruleflow.port property is set
true).
9.
drools-guvnor\src\main\java\org\drools\guvnor\server\builder\RuleFlowContentModelBuilder.java
BUG FIX in createNodesAndConnection method by adding guards to check for null values
before setting the X and Y coordinates of a node. I figured this was an omission, as
setting the node sizes has null-check guards. This fix allows the Guvnor to open migrated
.rfm to .rf ruleflow assets that will not have node size or coordinate data in their xml
definition.
ECLIPSE-PLUGIN
10.
drools-eclipse\org.drools.eclipse\src\main\java\org\drools\eclipse\flow\ruleflow\editor\RuleFlowModelEditor.java
MODIFIED createModel method to allow the opening of version 4 .rf (Graphical) ruleflow
files. The version 4 ruleflow is converted to a version 5 ruleflow model using the
RuleFlowMigrator class. This allows the version 4 .rf ruleflow to be viewed and modified
graphically using the drools 5 eclipse plug-in. Note that the underlying version 4 file is
not modified by the migration. Instead a warning dialog is displayed to tell the user
they're opening a drools 4 .rf and that any changes they make to the ruleflow will be
saved in drools 5 format (i.e. backwards compatibility with drools 4 will be lost if they
save). I suppose there may be a better solution than this, but I wanted to avoid changing
any user files without first warning the user.
Shahad
Migrating version 4 graphical ruleflows to version 5 in Eclipse
plugin and the Guvnor
-------------------------------------------------------------------------------------
Key: JBRULES-1945
URL:
https://jira.jboss.org/jira/browse/JBRULES-1945
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler, drools-compiler (flow), drools-eclipse,
drools-eclipse (flow), drools-guvnor
Affects Versions: 5.0.0.M4
Environment: n/a
Reporter: Shahad Ahmed
Assignee: Mark Proctor
Attachments: ruleflow_migratory.zip
Add improved support for migrating version 4 ruleflows to version 5. Drools 5 does not
support opening and migrating drools version 4 .rf (graphical) ruleflow files using the
drools eclipse plugin.
There is also a BUG in the Guvnor where version 4 ruleflow assets already in a
repository cannot be archived, saved etc. as a NullPointerException is thrown on the
server when any action is taken on such assets.
Also existing support for migrating .rfm ruleflow files in the compiler does not support
import or global definition inside split, join nodes etc.
Sorry for putting a whole bunch of ruleflow issues in a single JIRA, but they all turn
out to be interrelated and I have a patch that resolves all these issues that will be
attached to this JIRA
Shahad
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira