Daniel,
I was taking a look at StaxUtils class and I saw that there is some
code to verify which factory is created for XMLInputFactory. If I'm not
wrong it does not matter the jvm configuration it will always
create Woodstoxs XMLInputFactory. The same is not true for
XMLOutputFactory and you can end up using jvm default XMLOutputFactory.
Would that be a problem?
Ats,
Osvaldo Pina.
On Thu, Aug 29, 2013 at 11:43 AM, Osvaldo Pina <[email protected]>wrote:
>
> Thanks Daniel! I was my fault. I have a scenario where I have to change
> the transport technology of a component solution from ejb to REST without
> changing the application classpath (with uses the manifesto classpath
> pointing to jars in the file system). In order to do that I created a
> separated classloader programmatically that loads cxf and all of its
> dependencies and I forgot to set this classloader as the context
> classloader. Now I tried this and I think that the problem is solved.
>
>
> Ats,
> Osvaldo Pina.
>
>
>
>
> On Wed, Aug 28, 2013 at 6:34 PM, Daniel Kulp <[email protected]> wrote:
>
>>
>> On Aug 28, 2013, at 5:26 PM, Osvaldo Pina <[email protected]> wrote:
>> > I'm having a trouble int StaxUtils static initializer with cxf 2.7.6
>> > running in the IBM jkd 1.6. When it tries to create the XMLOutputFactory
>> > (XMLOutputFactory xof = XMLOutputFactory.newInstance()) a
>> > NoClassDefFoundError is thrown. The reason is that the factory property
>> > (javax.xml.stream.XMLOutputFactory) is set
>> > to com.ctc.wstx.stax.WstxOutputFactory and this class is not avaliable
>> > to javax.xml.stream.XMLOutputFactory classloader (the same applies to
>> > javax.xml.stream.XMLInputFactory).
>> > I'm thinking about changing the property to the IBM default value but I
>> > would like to know if it is safe.
>>
>> It's certainly not safe if your service accepts any sort of streaming
>> XML. You really need to use woodstox for that case.
>>
>> The question is why ISN'T it found in the class loader? It should be
>> using the context class loader which should be set properly in these
>> cases. Is there a full stack trace so we can see if there is a context
>> class loader or similar missing?
>>
>> That said, I just noticed the input factories are protected via a
>> try/catch that would trap this. The output factories are not. :-(
>>
>>
>> --
>> Daniel Kulp
>> [email protected] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
