Hi Michael, The code looks like it needs an @since Javadoc tag ;-)
Should this be a cue to cut a release? Gary On Wed, Apr 15, 2015 at 8:51 AM, Michael Glavassevich <mrgla...@ca.ibm.com> wrote: > Hi Peter, > > I think the SecureProcessingConfiguration [1] (not released yet) is > probably what you're looking for. With this XMLParserConfiguration you can > configure the limits using system properties and then override them > programmatically if some of your applications need a different > configuration than the global settings. > > DocumentBuilderFactory.setExpandEntityReferences() does not do what you > assumed. It only affects DOM construction, controlling whether > EntityReference [2] nodes are included in the DOM tree or not. So the > sub-tree underneath that entity reference has an EntityReference as its > parent or has the ancestor of the EntityReference (if entity references > are expanded) as its parent. It just flattens the structure of the DOM > tree a bit but that doesn't affect entity expansion done by the parser. > > Thanks. > > [1] > > http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/parsers/SecureProcessingConfiguration.java > [2] > > http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/EntityReference.html > > Michael Glavassevich > XML Technologies and WAS Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Peter Major <peter.ma...@forgerock.com> wrote on 04/01/2015 10:29:03 AM: > > > Hi, > > > > are there any plans to make the entity expansion limit setting a bit > > more friendlier? Currently the default limits in Xerces are a bit too > > permissive (100k entity expansion limit vs JDK's 64k), and they are also > > > a bit difficult to enforce: > > SecurityManager securityManager = new SecurityManager(); > > securityManager.setEntityExpansionLimit(5000); > > dbf.setAttribute("http://apache.org/xml/properties/security-manager";, > > securityManager); > > sp.setProperty("http://apache.org/xml/properties/security-manager";, > > securityManager); > > > > Which means that my utility library for XML parsing needs to explicitly > > depend on XercesImpl, or I need to trick around with reflection. > > I think the most unfortunate is that SecurityManager does not appear to > > be part of the JAXP API, and hence I'm not able to use Xerces' > > SecurityManager with JDK or the other way around. Would it be possible > > to implement the limits as attributes/properties/or even JVM properties > > as well (I suppose for a while that could still result in failures until > > > both parsers support the same set of attributes/properties/features)? > > > > On a different note, I think I probably misunderstood the purpose of > > setExpandEntityRefs(false) method on DocumentBuilderFactories. Whilst > > testing against the billion laughs attack, it looked like that > > setExpandEntityRefs didn't have any affect, and the entities were > > expanded in my XML document since I saw the error message about hitting > > the 100k entity expansion limit. Is this expected behavior? > > Also I couldn't really find a similar option for SAX parsers, am I meant > > > to use a lexical-handler there to prevent entity expansion? > > > > Thanks in advance, > > Peter > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > For additional commands, e-mail: j-users-h...@xerces.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
