У меня возникла странная проблема с Freemarker и загрузчиком классов, который я не использовал для 6.2. В принципе, в верхней части шаблона используется малая логика, использующая Oauth. Это использование отлично работает, и я не вижу проблемы с ним. Я попытался разместить вариацию Scribe везде, где мог, и даже удалить тот, который входит в ROOT.Liferay 7 - Freemarker: операция разворота, не соответствующая функции.
Что странно в том, что код успешно вызывает некоторые методы до того, как будет выбрано исключение, я предполагаю, что это не проблема загрузчика классов, а проблема с операцией разворачивания. Что-то изменилось в отношении этой функциональности?
Код: ${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)
Я только что упомянул, как я загрузчик классов должен был иметь дело с несколькими ClassNotFoundException или определения класса не нашел, чтобы добраться до этой точки. Это было как-то ожидаемо (непредсказуемое поведение) из-за репликации библиотеки.
Возможно ли, что у вас есть два разных класса, загруженных с именем 'org.scribe.model.ParameterList'? Потому что разворачивание третьего аргумента - довольно тривиальный случай. Последние важные изменения в этом поле были в 2.3.21 (2014-10-12), хотя это не должно приводить к такой регрессии. – ddekany
Я подозреваю, что это так, поскольку у меня были проблемы с классом def, а не с классом, который не найден. Но все исключения теперь исчезли, и если бы это было так, методы, предшествующие назначению, тоже потерпели бы неудачу, правильно? – Victor
Насколько я вижу из шаблона неудачи, возможно, что 'trueNTHConnect' использует другую версию проблемного класса, чем методы, которые были предложены перед ним. Во всяком случае, есть верный способ узнать это: измените FreeMarker в тех местах, где напечатаны имена классов, чтобы он также распечатывал хэш идентификаторов объектов класса. – ddekany