Re: [Libreoffice] [REVIEW] 3-4 cherry-pick fix to build with gcj 1.5.0

On Fri, 2011-11-04 at 14:01 +0100, Stephan Bergmann wrote:
> On 11/04/2011 12:41 PM, Caolán McNamara wrote:
> > i.e. com.sun.org.apache.xerces.internal.parsers.DOMParser is a
> > sun/oracle-only java api. Commit
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=04c5a36ab8d514cfbe8e40f4493787b2ab392ab5
> > (attached) I believe does the right thing, definitely builds anyway.
>
> Looking at the patch, 
> javax.xml.parsers.DocumentBuilderFactory.newInstance() smells like it 
> internally uses the context class loader, even if that is not documented 
> at 
> <http://download.oracle.com/javase/7/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#newInstance()>
>  
> (and at least in some Sun JRE 6 it indeed does so), so this could fail 
> if the context class loader is null---as can happen in LibO, see 
> <https://issues.apache.org/ooo/show_bug.cgi?id=102164#c6>.
>
> That is, the call to DocumentBuilderFactory.newInstance() within 
> OfficeDocumentReportTarget would need to be wrapped

Erm...

http://opengrok.libreoffice.org/search?q=DocumentBuilderFactory.newInstance&project=core&defs=&refs=&path=&hist=

Looks we're fairly riddled with this pattern. So presumably if this
problem affects DocumentBuilderFactory.newInstance we already suffer
from it in our xsltfilter and other places ?

C.