Когда делают мы получаем java.lang. NoSuchMethodError, даже когда банка/класс имеет particualar метод

$ наблюдаем () - это метод объекта Атрибуты , и поэтому его можно использовать только для наблюдения / наблюдения за изменением значения атрибут DOM. Он используется / вызывается только внутри директив. Используйте $ наблюдаем, когда вам нужно наблюдать / смотреть атрибут DOM, который содержит интерполяцию (т. Е. {{}}).
Например, attr1="Name: {{name}}", затем в директиве: attrs.$observe('attr1', ...).
(Если вы попытаетесь scope.$watch(attrs.attr1, ...), это не сработает из-за {{}} s - вы получите undefined.) Используйте $ watch для всего остального.

$ watch () сложнее. Он может наблюдать / наблюдать «выражение», где выражение может быть либо функцией, либо строкой. Если выражение является строкой, оно превращается в функцию $ parse 'd (т.е. оценивается как угловое выражение ) в функцию. (Именно эта функция вызывается каждый цикл дайджеста.) Строковое выражение не может содержать {{}}. $ watch - это метод объекта Scope , поэтому его можно использовать / вызывать везде, где у вас есть доступ к объекту области видимости, поэтому в

  • контроллер - любой контроллер - - созданная с помощью ng-view, ng-controller или контроллера директивы
  • связующая функция в директиве, поскольку она также имеет доступ к области действия

, поскольку строки оцениваемый как угловое выражение, $ watch часто используется, когда вы хотите наблюдать / наблюдать свойство model / scope. Например, attr1="myModel.some_prop", затем в функции контроллера или связи: scope.$watch('myModel.some_prop', ...) или scope.$watch(attrs.attr1, ...) (или scope.$watch(attrs['attr1'], ...)).
(Если вы попытаетесь attrs.$observe('attr1'), вы получите строку myModel.some_prop, что, вероятно, не то, что вы хотите.)

Как обсуждалось в комментариях к ответу @ PrimosK, все $ наблюдают и $ watches проверяются каждый цикл дайджеста .

Директивы с изолированными областями более сложны. Если используется синтаксис '@', вы можете $ наблюдаем или $ watch атрибут DOM, который содержит интерполяцию (то есть {{}}). (Причина, по которой он работает с $ watch, заключается в том, что синтаксис '@' выполняет для нас интерполяцию , поэтому $ watch видит строку без {{}}.) Чтобы упростить запоминание того, какой используйте, когда, я предлагаю использовать $ наблюдаем также для этого случая.

Чтобы помочь проверить все это, я написал Plunker , который определяет две директивы. Один (d1) не создает новую область, другой (d2) создает изолированную область. Каждая директива имеет одинаковые шесть атрибутов. Каждый атрибут - и $ наблюдаем, и $ наблюдаем.

Посмотрите журнал консоли, чтобы увидеть различия между $ наблюдаем и $ наблюдаем в функции связывания. Затем нажмите на ссылку и посмотрите, какие $ наблюдатели и $ watches запускаются изменениями свойств, сделанными обработчиком кликов.

Обратите внимание, что при запуске функции ссылки все атрибуты, содержащие {{}}, еще не оцениваются (поэтому, если вы попытаетесь проверить атрибуты, вы получите undefined). Единственный способ увидеть интерполированные значения - это использовать $ наблюдаю (или $ наблюдаем, если используем изолированную область с '@'). Следовательно, получение значений этих атрибутов является асинхронной операцией . (И именно поэтому нам нужны функции $ наблюдений и $ наблюдений.)

Иногда вам не нужны $ наблюдать или $ смотреть. Например, если ваш атрибут содержит число или логическое значение (не строку), просто оцените его один раз: attr1="22", а затем, скажем, в вашей функции связывания: var count = scope.$eval(attrs.attr1). Если это просто константная строка & ndash; attr1="my string" & ndash; затем просто используйте attrs.attr1 в вашей директиве (нет необходимости в $ eval ()).

См. Также пост группы Google Войты о выражениях $ watch.

10
задан Paŭlo Ebermann 4 July 2011 в 11:53
поделиться

6 ответов

Я обнаружил, что одна из сторонних jar-файлов была связана со старой версией библиотеки iText

4
ответ дан 3 December 2019 в 17:21
поделиться

Возможно, в вашем пути к классам появилась другая версия или что подпись этого конкретного метода изменилась после того, как вы скомпилировали свой класс

7
ответ дан 3 December 2019 в 17:21
поделиться
  1. Обычно такие проблемы возникают, если в вашем пути к классам есть другая версия проблемного класса, предшествующая той версии, которую вы использовали для компиляции (и которую вы декомпилировали, как было сказано ранее). Это часто случается, поскольку проблемы с путями к классам встречаются часто, в том числе и с экспертами, особенно. в контейнерах, где порядок загрузки библиотек не указан.

    Допустим, вы используете iText 1.a в своей среде IDE и выполняете компиляцию. Затем вы развертываете свое приложение в каком-нибудь контейнере, где предустановлен iText 1.b. Предустановленные библиотеки имеют приоритет, и когда b

    В вашем случае нет контейнера, но вы можете смешивать версии библиотек во время упаковки / развертывания или использовать разные пути к классам для разработки и выполнения.

    1271] jar находится не в пути к классам во время выполнения, а только во время компиляции. Но тогда вы получите NoClassDefFoundError при первом обращении к iText, что не так.

  2. Если сам iText пропустит стороннюю библиотеку, вы также получите NoClassDefFoundError при вызове метода, которому нужна неудовлетворенная зависимость.

7
ответ дан 3 December 2019 в 17:21
поделиться

Также может случиться так, что в пути к классам вашего апплета появятся две версии jar-файла, а подпись загруженной версии отличается от подписи, с которой был скомпилирован ваш код

0
ответ дан 3 December 2019 в 17:21
поделиться

возможно, есть другая версия этого класса в пути к классам до версии, которую вы декомпилировали.
edit : Или вы обновили пакет, но забыли развернуть его в пути к классам среды выполнения или не обновили путь к классам компиляции, т.е. ваша среда выполнения не синхронизирована с вашей средой времени компиляции.

public void completeRow () был представлен в 2.0.5. у вас должна быть версия до 2.0.5 в пути к классам среды выполнения. если вы все еще сталкиваетесь с этой проблемой, изучите путь к классам для запуска процесса. как указывалось ранее, вы компилируете с версией 2.1.5.

0
ответ дан 3 December 2019 в 17:21
поделиться

Это означает, что две версии класса PdfPTable находятся в вашем пути к классу. Два используемых вами jar-файла могли содержать разные версии одного и того же класса. Легкий способ выяснить это - сделать jar -tf для файлов jar в пути к классам и grep для вашего имени класса. Удалите устаревшую версию или измените порядок файлов jar в пути к классам.

2
ответ дан 3 December 2019 в 17:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: