Unable to view process definitions via probe: SAXParseExcept

[wolpert]

Folks-

  I'm using activiti 5.6, via the grails activiti plugin, without a problem. Process definitions are deployed correctly, and can view them correctly via the activiti RepositoryService class. But I get into a problem when I start up the activiti-probe and activiti-explorer webapplication. Attempts to view deployed processes in either causes the following exception in the server logs:

Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
        at org.activiti.engine.impl.util.xml.Parse.execute(Parse.java:133)
        … 31 more

The XML that was deployed via the grails-activiti plugin is correct, and as I mentioned, work fine with the activiti engine deployed, but they are completely unviewable using the distributed acitiviti webapplications.

To make matters stranger, if I deploy the same files via activiti-probe, there is no issue, and I can again use them just fine in the grails webapp via the grails-activiti plugin. Its the other way that there is this failure.

My configuration uses the same database instance for both, postgresql in this case. Activiti 5.6 and the XML files were generated via the eclipse designer. The exception suggests some data before the
<?xml version="1.0" encoding="UTF-8"?>
part of the xml file, but nothing is there… even checked with a hex editor just in case. And, it comes up validate when checking with a validating parser.

I'm not sure where to go from here… I've posted a request for help on the grails-activiti plugin side, but I wanted to post here in case someone could direct my attention to where the problem could originate from.

Any ideas?

Thanks

[wolpert]

I saw one reference that said if encoding is upper case it could cause this exception. I did change in the files that are generated by the eclipse tool from

<?xml version="1.0" encoding="UTF-8"?>

to

<?xml version="1.0" encoding="utf-8"?>

but the error still appears.  Still at a loss on this one.

[wolpert]

Does anyone have any insight into this problem?

[jbarrez]

The exception happens when there is something wrong as first element.

Did you try with a very minimal process? Can you post your process?

[wolpert]

The issues is independent of the complexity of the activiti xml file to import.

The process definition deployed using probe work fine. Meaning that once deployed, you can view the process definition without the error.

If the same XML is deployed using the grails-activiti plugin, reviewing the process fails with the exception show above when trying to review the process with activiti.

Correct me if I'm wrong, but probe is retrieving the XML from the core engine using an internal technique, and re-validating what was stored internally. If this is correct, then the part that is delivering the XML to probe is adding something to the XML to cause the error in probe validation of the XML. Remember that using this process defined by the XML does work fine…. so the core engine is working normally. I'm at a loss to explain what occurs during the deployment via grails-activiti that causes this error.

I'll come up with specific steps to reproduce this problem, but I'll do it with the next version of activiti (5.7) just in case that impacts the issue.

[jbarrez]

Okay, 15 aug is the target date.
Keep us posted, as I'm curious to what could lead to the problem.

[wolpert]

Turns out the problem was resolved at the database driver level. Specifically, the issue is in how the JDBC driver retrieves 'bytea' fields. With the application using 8.4-701 driver against the 9.0 database, the problem would manifest itself in retrieving the data 'in certain cases'. Upgraded to 9.0-801 and it worked fine. Also, the 9.0-801 driver was able to read from the 8.4 database without a problem. (Backwards compatible, not forward compatible, as one would reasonably expect.)

I cannot explain why some cases would work and others would not, but since upgrading the JDBC driver fixed all the problem cases, I'm calling it 'good'.

[ronald_van_kuij]

thanks for reporting back. Appreciated. Can you just add which db it was?

[wolpert]

PostgreSQL…

[jbarrez]

djeez … that's a very deep bug … kudos that you were able to find it!