On Tue, 5 Feb 2013, Mark Kimsal wrote:
I think I figured it out after browsing through the source. You should not make your own POIXMLProperties from the OPC package if you are dealing with an XWPFDocument, you should use doc.getProperties(). This is because when the document is written out, it calls its own getProperties().commit(). If the doc has never called its own getProperties() before, it makes a new one out of the opc package.
You should generally either work entirely at the OPCPackage layer, or at the POIXMLDocument layer. As you've found, if you do some things at the POIXMLDocument level and go around adding new things to the package, POIXMLDocument won't know and may well stomp on things when it writes back out again... POIXMLDocument should be fine with anything that was there when it was opened, but if you're playing at the low level and high level at the same time you need to make sure you don't accidently introduce your own pseudo race condition in a single thread!
I'm not sure if this behavior makes sense or not, shouldn't modifications to the properties though getUnderlyingProperties make changes via references which would propagate back up and affect any newly create POIXMLProperties created from the same OPC reference?
I'm not quite sure what you're saying, but if you have two POIXMLProperties instances open on the same OPCPackage, then both will have an in-memory representation. If you make conflicting changes to the two, only one will win at write-out time, as you've found!
(If it's something else, then you might be best to write a small unit test that shows up the problem)
Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
