On Thu, 2008-08-28 at 14:54 -0700, Mark Lundquist wrote: > Never mind. > > I went ahead as described, creating an XMLReader and setting the > EntityResolver by hand, then setting the feature. It turns out I was > given some bad advice that setting the "load-external-dtd" feature to > false would solve my problem (Xerces trying to connect to w3c.org in > spite of catalog-based EntityResolver), but it doesn't fix it anyway, > so... back to the drawing board.
not sure whether you are aware of http://svn.apache.org/viewvc/forrest/branches/update_cocoon_2.1.12-dev/main/webapp/WEB-INF/cocoon.xconf?diff_format=h&view=markup <entity-resolver logger="core.resolver"> <parameter name="catalog" value="resources/schema/catalog.xcat"/> <parameter name="verbosity" value="${org.apache.xml.resolver.verbosity}"/> </entity-resolver> maybe that helps. salu2 > —ml— > > > On Aug 28, 2008, at 10:22 AM, Mark Lundquist wrote: > > > > > Hi, > > > > I very much need to set the feature > > "http://apache.org/xml/features/nonvalidating/load-external-dtd > > " (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) > > on the Xerces parser wrapped by a JaxpParser instance (returned by > > manager lookup of SAXParser.role). > > > > I don't see a way to do it... it looks like JaxpParser doesn't > > expose an interface for it. JaxpParser buries the factory instances > > and the parser instances pretty thoroughly and doesn't provide any > > handles to set features, even in the component configuration. > > > > This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I > > can always just create my own parser instance if it comes down to > > that. Before I bother, does anybody know of a way to avoid the > > bother? Maybe I'm missing something... > > > > cheers, > > —ml— > > > > > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
