[#MCHANGES-75] Setting maxEntries too high causes a SAXParseException

Maven 2.x Changes Plugin

Setting maxEntries too high causes a SAXParseException

Created: 10/Apr/07 07:05 PM Updated: 10/Feb/08 05:49 AM

Component/s:

jira-report

Affects Version/s:

2.0-beta-2

Fix Version/s:

2.0

Time Tracking:

Not Specified

Environment:

maven 2.0.6

Description

« Hide

When I configure maxEntries == 500 and point the jira-report at http://jira.codehaus.org/browse/MNG, it fails to parse the resulting XML, saying it has exceeded 64,000 entity expansions (something to do with SAX). The error is:

org.xml.sax.SAXParseException: Parser has reached the entity expansion limit "64,000" set by the Application.

When I wget the URL that the changes plugin has generated:

http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=10500&sorter/field=created&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=500&reset=true&decorator=none

it shows results from XWIRE and XULUX...clearly not limited to MNG.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

John Casey - 10/Apr/07 07:09 PM

The same thing happens if I use the issueManagement URL:

http://jira.codehaus.org/secure/BrowseProject.jspa?pid=10500

(I had been using http://jira.codehaus.org/browse/MNG)

[ Permlink | « Hide ]

Dennis Lundberg - 07/Jul/07 07:09 PM

This seems to be a limit in the SAX parser. The error happens when there are a lot of entities like & and such in the file being parsed. I got around this one by specifying an explicit value for this limit on the command line

mvn site -DentityExpansionLimit=100000

When doing that, I only got issues for MNG - not any other project. So that may have been a glitch in codehaus JIRA at that time.

However, I have not been successful in doing this programatically in the plugin. You can set properties on the parser, but I don't know the correct id for the property.

[ Permlink | « Hide ]

Dennis Lundberg - 10/Feb/08 05:49 AM

I have documented a work-around in the FAQ.