You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Han Nguyen <hn...@us.ibm.com> on 2010/10/02 05:34:56 UTC
xmlParserAPIs.jar and xml-apis.jar cause class loader issue.
Ok, so we're back with this exception
> Caused by: java.lang.NoSuchMethodError:
> javax/xml/parsers/DocumentBuilder.reset()V
> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
Apparently, we found from Shindig dependency tree that caja depends on
xmlParserAPIs.jar, this library provides almost the same packages and
classes as the xml-apis.jar does which is a dependency for a couple of
shindig core modules. Depends on which jar got loaded by the class loader,
the error above would occur intermittently. We've seen it mostly on Linux
servers, and once on a Windows box.
Can Shindig modules and caja feature reference either xml-apis.jar or
xmlParserAPIs.jar so there'll be 1 jar as the net?
What would be other alternatives to solve this problem?
Has anyone had solution for this or should I open a bug?
Thanks much!
Han
From: Paul Lindner <pl...@linkedin.com>
To: dev@shindig.apache.org
Date: 09/03/2010 07:40 PM
Subject: Re: Error deploying Shindig trunk on WAS 7
Sent by: lindner@inuus.com
Check for old versions of xml-apis-*.jar
That's where this class is defined.
On Fri, Sep 3, 2010 at 11:28 AM, Han Nguyen <hn...@us.ibm.com> wrote:
> Hi,
> We're testing Shindig (trunk) deployment on multiple app servers, and
ran
> into the problem below on WAS 7.0.0.9
>
> At first, it appears that there's classloader order problem with an app
> using common-codec 1.3 load first, and shindig couldn't get to its
current
> references for common-codec 1.4 APIs with the exception below
>
> [Servlet Error]-[xml-to-html]: java.lang.NoSuchMethodError:
> org/apache/commons/codec/binary/Base64.encodeBase64URLSafe([B)[B
> at
>
>
org.apache.shindig.common.crypto.BasicBlobCrypter.wrap(BasicBlobCrypter.java:152)
> at
>
>
org.apache.shindig.auth.BasicSecurityToken.<init>(BasicSecurityToken.java:83)
> at
>
>
org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:83)
> at
>
>
org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:66)
> at
>
>
org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthenticationHandler.java:56)
> at
>
>
org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>
> We then set the classloader priority to Shindig and the exception above
> went away, but new error pops up, and we don't know how to get around
it.
> Has anyone seen the below error and/or has any pointer?
>
> Caused by: java.lang.NoSuchMethodError:
> javax/xml/parsers/DocumentBuilder.reset()V
> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>
>
> Thanks!
> Han
--
Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
Re: xmlParserAPIs.jar and xml-apis.jar cause class loader issue.
Posted by Paul Lindner <li...@inuus.com>.
I removed instances of xmlParserApis from any shindig pom.xml files.
I then used an "exclusion" in the caja dep portion of the pom.xml to
remove xmlParserAPIs
+ <exclusions>
+ <!-- force use of xml-apis until caja fixes their pom -->
+ <exclusion>
+ <groupId>xerces</groupId>
+ <artifactId>xmlParserAPIs</artifactId>
+ </exclusion>
+ </exclusions>
On Mon, Oct 4, 2010 at 8:43 PM, Zhenhua Guo <je...@gmail.com> wrote:
> I am curious about how you (and Paul) solved the problem.
>
> Geald
>
> On Mon, Oct 4, 2010 at 12:37 PM, Han Nguyen <hn...@us.ibm.com> wrote:
>> Thanks Paul!
>>
>>
>>
>> From: Paul Lindner <li...@inuus.com>
>> To: dev@shindig.apache.org
>> Date: 10/03/2010 11:45 AM
>> Subject: Re: xmlParserAPIs.jar and xml-apis.jar cause class loader
>> issue.
>>
>>
>>
>> I just committed a fix for this to trunk. I'll make sure it gets
>> ported to 2.0.1
>>
>> On Fri, Oct 1, 2010 at 8:34 PM, Han Nguyen <hn...@us.ibm.com> wrote:
>>> Ok, so we're back with this exception
>>>> Caused by: java.lang.NoSuchMethodError:
>>>> javax/xml/parsers/DocumentBuilder.reset()V
>>>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>>>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>>>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>>>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>>
>>> Apparently, we found from Shindig dependency tree that caja depends on
>>> xmlParserAPIs.jar, this library provides almost the same packages and
>>> classes as the xml-apis.jar does which is a dependency for a couple of
>>> shindig core modules. Depends on which jar got loaded by the class
>> loader,
>>> the error above would occur intermittently. We've seen it mostly on
>> Linux
>>> servers, and once on a Windows box.
>>> Can Shindig modules and caja feature reference either xml-apis.jar or
>>> xmlParserAPIs.jar so there'll be 1 jar as the net?
>>> What would be other alternatives to solve this problem?
>>> Has anyone had solution for this or should I open a bug?
>>>
>>> Thanks much!
>>> Han
>>>
>>>
>>>
>>> From: Paul Lindner <pl...@linkedin.com>
>>> To: dev@shindig.apache.org
>>> Date: 09/03/2010 07:40 PM
>>> Subject: Re: Error deploying Shindig trunk on WAS 7
>>> Sent by: lindner@inuus.com
>>>
>>>
>>>
>>> Check for old versions of xml-apis-*.jar
>>>
>>> That's where this class is defined.
>>>
>>> On Fri, Sep 3, 2010 at 11:28 AM, Han Nguyen <hn...@us.ibm.com> wrote:
>>>
>>>> Hi,
>>>> We're testing Shindig (trunk) deployment on multiple app servers, and
>>> ran
>>>> into the problem below on WAS 7.0.0.9
>>>>
>>>> At first, it appears that there's classloader order problem with an app
>>>> using common-codec 1.3 load first, and shindig couldn't get to its
>>> current
>>>> references for common-codec 1.4 APIs with the exception below
>>>>
>>>> [Servlet Error]-[xml-to-html]: java.lang.NoSuchMethodError:
>>>> org/apache/commons/codec/binary/Base64.encodeBase64URLSafe([B)[B
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.common.crypto.BasicBlobCrypter.wrap(BasicBlobCrypter.java:152)
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.auth.BasicSecurityToken.<init>(BasicSecurityToken.java:83)
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:83)
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:66)
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthenticationHandler.java:56)
>>>> at
>>>>
>>>>
>>>
>> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>>>>
>>>> We then set the classloader priority to Shindig and the exception above
>>>> went away, but new error pops up, and we don't know how to get around
>>> it.
>>>> Has anyone seen the below error and/or has any pointer?
>>>>
>>>> Caused by: java.lang.NoSuchMethodError:
>>>> javax/xml/parsers/DocumentBuilder.reset()V
>>>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>>>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>>>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>>>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>>>
>>>>
>>>> Thanks!
>>>> Han
>>>
>>>
>>>
>>>
>>> --
>>> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>>>
>>>
>>
>>
>>
>> --
>> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>>
>>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: xmlParserAPIs.jar and xml-apis.jar cause class loader issue.
Posted by Zhenhua Guo <je...@gmail.com>.
I am curious about how you (and Paul) solved the problem.
Geald
On Mon, Oct 4, 2010 at 12:37 PM, Han Nguyen <hn...@us.ibm.com> wrote:
> Thanks Paul!
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org
> Date: 10/03/2010 11:45 AM
> Subject: Re: xmlParserAPIs.jar and xml-apis.jar cause class loader
> issue.
>
>
>
> I just committed a fix for this to trunk. I'll make sure it gets
> ported to 2.0.1
>
> On Fri, Oct 1, 2010 at 8:34 PM, Han Nguyen <hn...@us.ibm.com> wrote:
>> Ok, so we're back with this exception
>>> Caused by: java.lang.NoSuchMethodError:
>>> javax/xml/parsers/DocumentBuilder.reset()V
>>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>
>> Apparently, we found from Shindig dependency tree that caja depends on
>> xmlParserAPIs.jar, this library provides almost the same packages and
>> classes as the xml-apis.jar does which is a dependency for a couple of
>> shindig core modules. Depends on which jar got loaded by the class
> loader,
>> the error above would occur intermittently. We've seen it mostly on
> Linux
>> servers, and once on a Windows box.
>> Can Shindig modules and caja feature reference either xml-apis.jar or
>> xmlParserAPIs.jar so there'll be 1 jar as the net?
>> What would be other alternatives to solve this problem?
>> Has anyone had solution for this or should I open a bug?
>>
>> Thanks much!
>> Han
>>
>>
>>
>> From: Paul Lindner <pl...@linkedin.com>
>> To: dev@shindig.apache.org
>> Date: 09/03/2010 07:40 PM
>> Subject: Re: Error deploying Shindig trunk on WAS 7
>> Sent by: lindner@inuus.com
>>
>>
>>
>> Check for old versions of xml-apis-*.jar
>>
>> That's where this class is defined.
>>
>> On Fri, Sep 3, 2010 at 11:28 AM, Han Nguyen <hn...@us.ibm.com> wrote:
>>
>>> Hi,
>>> We're testing Shindig (trunk) deployment on multiple app servers, and
>> ran
>>> into the problem below on WAS 7.0.0.9
>>>
>>> At first, it appears that there's classloader order problem with an app
>>> using common-codec 1.3 load first, and shindig couldn't get to its
>> current
>>> references for common-codec 1.4 APIs with the exception below
>>>
>>> [Servlet Error]-[xml-to-html]: java.lang.NoSuchMethodError:
>>> org/apache/commons/codec/binary/Base64.encodeBase64URLSafe([B)[B
>>> at
>>>
>>>
>>
> org.apache.shindig.common.crypto.BasicBlobCrypter.wrap(BasicBlobCrypter.java:152)
>>> at
>>>
>>>
>>
> org.apache.shindig.auth.BasicSecurityToken.<init>(BasicSecurityToken.java:83)
>>> at
>>>
>>>
>>
> org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:83)
>>> at
>>>
>>>
>>
> org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:66)
>>> at
>>>
>>>
>>
> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthenticationHandler.java:56)
>>> at
>>>
>>>
>>
> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>>>
>>> We then set the classloader priority to Shindig and the exception above
>>> went away, but new error pops up, and we don't know how to get around
>> it.
>>> Has anyone seen the below error and/or has any pointer?
>>>
>>> Caused by: java.lang.NoSuchMethodError:
>>> javax/xml/parsers/DocumentBuilder.reset()V
>>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>>
>>>
>>> Thanks!
>>> Han
>>
>>
>>
>>
>> --
>> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>>
>>
>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
>
Re: xmlParserAPIs.jar and xml-apis.jar cause class loader issue.
Posted by Han Nguyen <hn...@us.ibm.com>.
Thanks Paul!
From: Paul Lindner <li...@inuus.com>
To: dev@shindig.apache.org
Date: 10/03/2010 11:45 AM
Subject: Re: xmlParserAPIs.jar and xml-apis.jar cause class loader
issue.
I just committed a fix for this to trunk. I'll make sure it gets
ported to 2.0.1
On Fri, Oct 1, 2010 at 8:34 PM, Han Nguyen <hn...@us.ibm.com> wrote:
> Ok, so we're back with this exception
>> Caused by: java.lang.NoSuchMethodError:
>> javax/xml/parsers/DocumentBuilder.reset()V
>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>
> Apparently, we found from Shindig dependency tree that caja depends on
> xmlParserAPIs.jar, this library provides almost the same packages and
> classes as the xml-apis.jar does which is a dependency for a couple of
> shindig core modules. Depends on which jar got loaded by the class
loader,
> the error above would occur intermittently. We've seen it mostly on
Linux
> servers, and once on a Windows box.
> Can Shindig modules and caja feature reference either xml-apis.jar or
> xmlParserAPIs.jar so there'll be 1 jar as the net?
> What would be other alternatives to solve this problem?
> Has anyone had solution for this or should I open a bug?
>
> Thanks much!
> Han
>
>
>
> From: Paul Lindner <pl...@linkedin.com>
> To: dev@shindig.apache.org
> Date: 09/03/2010 07:40 PM
> Subject: Re: Error deploying Shindig trunk on WAS 7
> Sent by: lindner@inuus.com
>
>
>
> Check for old versions of xml-apis-*.jar
>
> That's where this class is defined.
>
> On Fri, Sep 3, 2010 at 11:28 AM, Han Nguyen <hn...@us.ibm.com> wrote:
>
>> Hi,
>> We're testing Shindig (trunk) deployment on multiple app servers, and
> ran
>> into the problem below on WAS 7.0.0.9
>>
>> At first, it appears that there's classloader order problem with an app
>> using common-codec 1.3 load first, and shindig couldn't get to its
> current
>> references for common-codec 1.4 APIs with the exception below
>>
>> [Servlet Error]-[xml-to-html]: java.lang.NoSuchMethodError:
>> org/apache/commons/codec/binary/Base64.encodeBase64URLSafe([B)[B
>> at
>>
>>
>
org.apache.shindig.common.crypto.BasicBlobCrypter.wrap(BasicBlobCrypter.java:152)
>> at
>>
>>
>
org.apache.shindig.auth.BasicSecurityToken.<init>(BasicSecurityToken.java:83)
>> at
>>
>>
>
org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:83)
>> at
>>
>>
>
org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:66)
>> at
>>
>>
>
org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthenticationHandler.java:56)
>> at
>>
>>
>
org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>>
>> We then set the classloader priority to Shindig and the exception above
>> went away, but new error pops up, and we don't know how to get around
> it.
>> Has anyone seen the below error and/or has any pointer?
>>
>> Caused by: java.lang.NoSuchMethodError:
>> javax/xml/parsers/DocumentBuilder.reset()V
>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>
>>
>> Thanks!
>> Han
>
>
>
>
> --
> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: xmlParserAPIs.jar and xml-apis.jar cause class loader issue.
Posted by Paul Lindner <li...@inuus.com>.
I just committed a fix for this to trunk. I'll make sure it gets
ported to 2.0.1
On Fri, Oct 1, 2010 at 8:34 PM, Han Nguyen <hn...@us.ibm.com> wrote:
> Ok, so we're back with this exception
>> Caused by: java.lang.NoSuchMethodError:
>> javax/xml/parsers/DocumentBuilder.reset()V
>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>
> Apparently, we found from Shindig dependency tree that caja depends on
> xmlParserAPIs.jar, this library provides almost the same packages and
> classes as the xml-apis.jar does which is a dependency for a couple of
> shindig core modules. Depends on which jar got loaded by the class loader,
> the error above would occur intermittently. We've seen it mostly on Linux
> servers, and once on a Windows box.
> Can Shindig modules and caja feature reference either xml-apis.jar or
> xmlParserAPIs.jar so there'll be 1 jar as the net?
> What would be other alternatives to solve this problem?
> Has anyone had solution for this or should I open a bug?
>
> Thanks much!
> Han
>
>
>
> From: Paul Lindner <pl...@linkedin.com>
> To: dev@shindig.apache.org
> Date: 09/03/2010 07:40 PM
> Subject: Re: Error deploying Shindig trunk on WAS 7
> Sent by: lindner@inuus.com
>
>
>
> Check for old versions of xml-apis-*.jar
>
> That's where this class is defined.
>
> On Fri, Sep 3, 2010 at 11:28 AM, Han Nguyen <hn...@us.ibm.com> wrote:
>
>> Hi,
>> We're testing Shindig (trunk) deployment on multiple app servers, and
> ran
>> into the problem below on WAS 7.0.0.9
>>
>> At first, it appears that there's classloader order problem with an app
>> using common-codec 1.3 load first, and shindig couldn't get to its
> current
>> references for common-codec 1.4 APIs with the exception below
>>
>> [Servlet Error]-[xml-to-html]: java.lang.NoSuchMethodError:
>> org/apache/commons/codec/binary/Base64.encodeBase64URLSafe([B)[B
>> at
>>
>>
> org.apache.shindig.common.crypto.BasicBlobCrypter.wrap(BasicBlobCrypter.java:152)
>> at
>>
>>
> org.apache.shindig.auth.BasicSecurityToken.<init>(BasicSecurityToken.java:83)
>> at
>>
>>
> org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:83)
>> at
>>
>>
> org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:66)
>> at
>>
>>
> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthenticationHandler.java:56)
>> at
>>
>>
> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>>
>> We then set the classloader priority to Shindig and the exception above
>> went away, but new error pops up, and we don't know how to get around
> it.
>> Has anyone seen the below error and/or has any pointer?
>>
>> Caused by: java.lang.NoSuchMethodError:
>> javax/xml/parsers/DocumentBuilder.reset()V
>> at org.apache.shindig.common.xml.XmlUtil.<clinit>(XmlUtil.java:121)
>> at java.lang.J9VMInternals.initializeImpl(Native Method)
>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
>> at org.apache.shindig.gadgets.features.FeatureParser.parse(FeaturePa
>>
>>
>> Thanks!
>> Han
>
>
>
>
> --
> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner