Hello again. I'm back :) The xmlbeans team suggests that secure processing options be set by assigning an appropriate XMLReader using the XMLOptions api after setting the various processing features. See [1] for reference to setting features in javax.xml.parser* factories
http://xmlbeans.apache.org/docs/2.6.0/reference/org/apache/xmlbeans/XmlOptions.html#setLoadUseXMLReader(org.xml.sax.XMLReader) One possible solution would be to create in intermediate class that is an immediate ancestor for all the current implementations of the XMLObject interface ... and which is extended by those classes... Then, use that class as a place to determine if the user wants to use custom XMLOptions... for example: public class CTBubbleScaleImpl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements org.openxmlformats.schemas.drawingml.x2006.chart.CTBubbleScale ... create something like org.poi.something.somethingelse.XmlContextContentImpl extends org.apache.xmlbeans.impl.values.XmlComplexContentImpl and override all the methods that have an XmlOptions alternate signature ... in those, check for user supplied XmlOptions and call the appropriate parent method But I am just jabbing into the air :) You all may have another, better approach. I don't know for example if the above would cover all the cases, yet... I just found that one hotspot where xmlbeans calls where being made. WDYT? [1] http://docs.oracle.com/javase/6/docs/api/javax/xml/parsers/SAXParserFactory.html#setFeature(java.lang.String, boolean) http://docs.oracle.com/javase/6/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#setFeature(java.lang.String, boolean) http://xerces.apache.org/xerces2-j/features.html On Mon, Jan 14, 2013 at 3:14 PM, Jon Gorrono <[email protected]> wrote: > Thank you :) > > On Mon, Jan 14, 2013 at 1:35 PM, Nick Burch <[email protected]> wrote: >> On Mon, 14 Jan 2013, Jon Gorrono wrote: >>> >>> OK, I'll check with xmlbeans ... hopefully they won't punt back citing >>> user-configuration options. >> >> >> If there are user-configuration parts that matter, let us know and we can >> try to help you find the relevent bits of the POI source code! >> >> Nick >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Jon Gorrono > PGP Key: 0x5434509D - > http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index} > http{middleware.ucdavis.edu} -- Jon Gorrono PGP Key: 0x5434509D - http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index} http{middleware.ucdavis.edu} On Mon, Jan 14, 2013 at 3:14 PM, Jon Gorrono <[email protected]> wrote: > Thank you :) > > On Mon, Jan 14, 2013 at 1:35 PM, Nick Burch <[email protected]> wrote: >> On Mon, 14 Jan 2013, Jon Gorrono wrote: >>> >>> OK, I'll check with xmlbeans ... hopefully they won't punt back citing >>> user-configuration options. >> >> >> If there are user-configuration parts that matter, let us know and we can >> try to help you find the relevent bits of the POI source code! >> >> Nick >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Jon Gorrono > PGP Key: 0x5434509D - > http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index} > http{middleware.ucdavis.edu} -- Jon Gorrono PGP Key: 0x5434509D - http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index} http{middleware.ucdavis.edu} --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
