JBoss Drools Guvnor zu Workbench Migrationsproblem

Wir haben vor kurzem versucht, unsere Regelwissensbasis von Guvnor zu Workbench zu migrieren. Wir verwenden das Migrationswerkzeug drools-wb-jcr2vfs-distribution-6.4.0.Final, um die Migration durchzuführen. Wir konnten genug Probleme durcharbeiten, um den ersten Teil der Migration abzuschließen, der der Export der jcr ist, aber wir erhalten nun einen Fehler beim Import in vfs. Die Protokolldateien zeigen die folgenden Stack-Trace:JBoss Drools Guvnor zu Workbench Migrationsproblem

15:14:20.910 [main] INFO o.d.w.jcr2vfsmigration.VfsImporter - VFS import started. Reading from import directory C:\drools-wb-jcr2vfs-distribution-6.4.0.Final\bin\tmp-jcr2vfs. 
15:14:20.972 [main] INFO o.d.w.j.v.ModuleAssetImporter - Module import started 
15:14:20.988 [main] INFO o.d.w.j.v.ModuleAssetImporter -  Importing module [ProductProcessing] (UUID=e6dfb921-bc91-4bbe-93eb-db1627f86e03) 
15:14:22.316 [main] ERROR o.d.w.j.v.ModuleAssetImporter - Exception while importing assets for module 'ProductProcessing'. 
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence. 
    at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source) ~[na:1.8.0_77] 
    at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source) ~[na:1.8.0_77] 
    at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) ~[na:1.8.0_77] 
    at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAssets(ModuleAssetImporter.java:224) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importModule(ModuleAssetImporter.java:179) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAll(ModuleAssetImporter.java:137) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter$Proxy$_$$_WeldClientProxy.importAll(ModuleAssetImporter$Proxy$_$$_WeldClientProxy.java) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.VfsImporter.importAll(VfsImporter.java:65) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.VfsImporter$Proxy$_$$_WeldClientProxy.importAll(VfsImporter$Proxy$_$$_WeldClientProxy.java) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.launchImport(VfsImporterLauncher.java:56) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.run(VfsImporterLauncher.java:48) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
    at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.main(VfsImporterLauncher.java:33) [drools-wb-jcr2vfs-import-6.4.0.Final.jar:6.4.0.Final] 
15:14:22.347 [main] INFO o.d.w.j.v.ModuleAssetImporter -  Importing module [defaultPackage] (UUID=1eefd28f-6222-4747-a695-7f22c6d23535) 
15:14:22.800 [main] INFO o.d.w.j.v.ModuleAssetImporter -  Importing module [globalArea] (UUID=c08ab4cc-4c4a-4d55-99eb-771e9553f302) 
15:14:23.253 [main] INFO o.d.w.j.v.ModuleAssetImporter - Module import ended

Der Fehler scheint darauf hinzudeuten, dass es eine Codierung Problem in der modules.xml, die durch den Export erstellt wurde. Irgendwelche Vorschläge zur Lösung würden sehr geschätzt werden.

Quelle

2016-05-18 Bill W

Was ist die Verarbeitungsanweisung für Ihre XML-Datei? Benennt es die tatsächliche Kodierung der Datei? Wenn das erste Byte einer UTF-8-Sequenz ungültig ist, haben Sie ein Zeichen> 0x7F, das keine ordnungsgemäße UTF-8-Sequenz startet, sondern in einer oder mehreren 8-Bit-Codierungen gültig ist. Häufig '' Hilft, aber Sie haben vielleicht etwas Windowsy oder seltsamer. – laune

Die XML-Datei benennt die Codierung nicht wirklich. Die erste Zeile in der XML beginnt mit ' 9b6ef7f2-8b86-4d30-892b-34c119941a29 GLOBAL globalArea - globalarea 9b6ef7f2-8b86-4d30-892b-34c119941a29 887b1280-e813-4027-bd7a-873f6ca247f5 NORMAL ' –

Nun, da bist du. Der XML-Parser kann aufgrund des Systemstandards eine Codierung annehmen. – laune

@laune Danke für Ihre Hilfe. Sie haben richtig angenommen, dass es UTF-8 angenommen hat. Als ich in jede der XML-Dateien, die der Importauftrag verarbeitet hat,

<?xml version="1.0" encoding="ISO-8859-1"?>

platziert wurde, begann es zu arbeiten. Ich glaube, es war ein Windowsy-Problem, das vom Migrationstool nicht erwartet wurde. Danke nochmal für die Hilfe.

Quelle

2016-05-19 15:53:42

JBoss Drools Guvnor zu Workbench Migrationsproblem

Antwort

Verwandte Themen