NoClassDef found : PeopleService / SSO / Google Apps Integration (Pro)

Help / Discuss
, , ,
1

Hello,

The Google Apps Integration (Pro), version 2.6.1 is not working on our wiki.
XWiki 15.10.7
Tomcat 8.5 (last version 8.5.99)
Java 11 (we’ll move up for XWiki 16…)

When connecting, it processes the login and password of the google account (google account pages).
But when redirecting to XWiki, the page is :
“Authentification Google Apps”

with this message :

Erreur dans l'exécution de la macro [velocity]. Cause : 
[Could not initialize class com.google.api.services.people.v1.PeopleService]. 
Cliquer sur ce message pour voir plus de détails.

The class : com.google.api.services.people.v1.PeopleService
is not found.

And the details (extract of the whole java exception) :

java.lang.NoClassDefFoundError: Could not initialize class com.google.api.services.people.v1.PeopleService
 at com.google.api.services.people.v1.PeopleService$Builder.build(PeopleService.java:2496)
 at com.google.api.services.people.v1.PeopleService$Builder$build$0.call(Unknown Source)
 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
 at GoogleAppsGroovy.updateUser(Script_765581af138cbaea069885f002925edc.groovy:348)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
 at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
 at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
 at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
 at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:704)
 at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:75)
 at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:242)
 at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
 at org.apache.velocity.Template.merge(Template.java:358)
 at org.apache.velocity.Template.merge(Template.java:262)
 at org.xwiki.velocity.internal.InternalVelocityEngine.evaluate(InternalVelocityEngine.java:225)

It seems it does not find one lib,…
Suprising ! ???

I have checked the installation of the extension,
and deleted it, and reinstalled it.
Same error.

The dependencies tab shows :

Cette extension dépend de:

Is there a extension dependance missing ?

Where does this error come from ?
How to investigate, or solve this ?

Please, any help…

2

This is the forum for the xwiki.org community and not really the right place to get support for paid apps from XWiki SAS. While employees of XWiki SAS (like me) regularly visit this forum, it would be best to contact XWiki SAS, the company developing this extension, directly. If you have bought this extension, the license comes with a support contract, providing you the ability to get direct professional support from XWiki SAS. If not, you could also report an issue in the issue tracker of the app. If in doubt, please contact XWiki SAS.

3

Thank you !
I did not know about this.
I’ll see with the support… and may come back here to write the solution, if it is interesting for general use of XWiki…

4

Hi,

For info.
This might be of some help, when trouble with extensions installation, in general.

After searching and trying, the problem was coming from an installation of the extension by UserA, disabling of UserA,
then new user for Admin : UserB.
UserA is disabled.
Then configuration of the extension by UserB,
test by UserB, but errors.
then remove of the extension by UserB,
then one dependency extension is “declassed” instead of remove, by UserB (a mistake, but useful to learn…)
then upgrade of the XWiki (from v13 to v15). We had to do it, … it took place in the middle of the Extension install.
then reinstall of the extension by UserB,
some trials of Extension by UserB : errors.
and… big mess in the extension documents.

Some of the errors and trouble came from the fact that DocumentX of the extension was created and last modified by UserA.
With UserA disabled, these document could not be used as programs (“program” right is disabled).
Hence, the Extension, installed by UserB, bumped into former documents that remained from previous install, and could not be executed as programs.

This was resolved by :
UserB removes the Extension.
UserB removes by hand (document by document) some of the Extension documents. The one that was belonging to UserA. Those documents were remaining, with “last modification by UserA”.
UserB Install the Extension, configure,
and it works smoothly.

To know the documents that were remaining : I looked at the documents that belongs to UserA.
And saw some that were related to the Extension.
(I don’t remember exactly which one, but there was a few of them, … )
(only the principle of the resolution is usefull…).

I guess that when UserB was trying to remove the extension, some documents could not be removed by UserB, because made by UserA.
The dependency Extension declassed, and upgrade, and many try and errors also did made a mess with some documents of the Extension.

What put me on tracks of the problems of documents still belonging to UserA :

  • The logs of XWiki (standard config)
  • There was an exception that a doc could not run its program, because there was no “program” rights.
  • Then, searching for that document, reminding that UserA is still there but had been disabled, … etc… I spoted the wrong documents.
  • I also desintalled once more the Extension, and saw that those documents where not removed from the system.
  • Hence, to remove them by hand (removing the docs themselves, not only removing the extensions and dependency extensions).

Globally, this was not a usual situation.
Disabling a user that was admin is making some tricky situation, but nothing that cannot be solved.

Hope it helps…