2016-03-25 2 views
0

Ich habe ein seltsames Problem mit Freemarker und dem Classloader, das ich unter 6.2 nicht benutzt habe. Grundsätzlich gibt es eine kleine Logik oben auf der Vorlage, die Oauth verwendet. Dies funktioniert gut und ich kann kein Problem damit sehen. Ich habe versucht, eine Variation des Scribes zu platzieren, wo immer ich konnte, und sogar die, die in den ROOT kommt, zu löschen.Liferay 7 - Freemarker: Unwrap-Operation, die nicht mit der Funktionssignatur übereinstimmt

Was ist seltsam ist, dass der Code erfolgreich einige Methoden vor dem Auslösen der Ausnahme aufgerufen wird, ich denke, dann ist es kein Problem Klassenloader, sondern ein Problem mit der Unwrap-Operation. Hat sich etwas in Bezug auf diese Funktionalität geändert?

Code: ${callbackParameters.add(TrueNTHOAuthConstants.REDIRECT, portalUtil.getCurrentCompleteURL(request))}
<#assign trueNTHConnectLoginURL = trueNTHConnect.getAuthorizationUrl(companyId,1, callbackParameters) /> (Exception at this line)

FreeMarker template error: No compatible overloaded variation was found; can't convert (unwrap) the 3rd argument to the desired Java type. The FTL type of the argument values were: number (wrapper: f.t.SimpleNumber), number (wrapper: f.t.SimpleNumber), extended_hash+string (org.scribe.model.ParameterList wrapped into f.e.b.StringModel). **The matching overload was searched among these members**: com.sun.proxy.$Proxy799.getAuthorizationUrl(long), com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList, org.scribe.model.ParameterList), com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList)

Ich habe erwähnt nur den Klassenlader als ich mit mehrere ClassNotFoundException oder Klassendefinition zu tun hatte nicht zu diesem Punkt kommen gefunden. Dies wurde aufgrund der Bibliotheksreplikation irgendwie erwartet (unvorhersehbares Verhalten).

+0

Ist es möglich, dass Sie zwei verschiedene Klassen mit 'org.scribe.model.ParameterList' Namen geladen haben? Das Auspacken des 3. Arguments ist ein ziemlich trivialer Fall. Die letzten wichtigen Änderungen in diesem Bereich wurden in 2.3.21 (2014-10-12) vorgenommen, sollten aber nicht zu einer solchen Regression führen. – ddekany

+0

Ich vermute, dass das der Fall ist, da ich Probleme mit der Klasse Def anstatt Klasse nicht gefunden hatte. Aber alle Ausnahmen sind jetzt weg und wenn das der Fall wäre, würden auch die Methoden vor der Zuweisung fehlschlagen, richtig? – Victor

+1

So viel ich von der fehlerhaften Vorlage sehe, könnte es genauso gut möglich sein, dass 'trueNTHConnect' eine andere Version der problematischen Klasse verwendet als die zuvor aufgerufenen Methoden. Wie auch immer, es gibt einen sicheren Weg, es herauszufinden: Ändern Sie FreeMarker an den Stellen, an denen die Klassennamen gedruckt werden, so dass auch der Identitätshash der 'Class' Objekte gedruckt wird. – ddekany

Antwort

0

Es ist möglich, dass Sie zwei verschiedene Klassen mit dem Namen org.scribe.model.ParameterList geladen haben. So verwendet trueNTHConnect eine andere Version der problematischen Klasse als die zuvor aufgerufenen Methoden. Die JVM wird sie als völlig unterschiedliche inkompatible Klassen sehen, daher gibt es keine übereinstimmende Überladung.

Es gibt einen sicheren Weg, es herauszufinden: debuggen oder modifizieren FreeMarker an den Stellen, wo die Klassennamen gedruckt werden, so dass es auch den Identitätshash der Klassenobjekte ausgibt.

Verwandte Themen