Grails and PlayORM

Question

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

У меня возникли трудности с использованием PlayORM с Grails: 1. Существует конфликт зависимостей, который я мог бы решить, удалив «logback-classic.jar» из папки BuildPath и «/ lib», но сохраняя «commons-logging» ». Подробнее см. Ниже. 2. Теперь я получаю некоторые странные исключения PlayORM, которые я думаю, скорее всего, из-за удаленные зависимости:

| Loading Grails 2.2.1 
| Configuring classpath. 
| Environment set to development..... 
| Packaging Grails application..... 
| Running Grails application 
| Error 2013-06-18 10:38:31,057 [Thread-8] ERROR plugins.DefaultGrailsPlugin - Cannot generate controller logic for scaffolded class class nosql.Transaction. It is not a domain class! 
| Server running. Browse to http://localhost:8080/gibb 
java.lang.RuntimeException: Failure scanning class(see chained exception)=class com.alvazan.orm.api.z8spi.meta.DboTableMeta 
    at com.alvazan.orm.layer0.base.MyClassAnnotationDiscoveryListener.scanClass(MyClassAnnotationDiscoveryListener.java:50) 
....... 
**Caused by: java.lang.RuntimeException: Failure scanning field=private java.lang.String com.alvazan.orm.api.z8spi.meta.DboTableMeta.columnFamily for class=DboTableMeta 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.inspectField(ScannerForClass.java:209) 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.scanFields(ScannerForClass.java:202) 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.scanSingle(ScannerForClass.java:122) 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.addClass(ScannerForClass.java:80) 
    at com.alvazan.orm.layer0.base.MyClassAnnotationDiscoveryListener.scanClass(MyClassAnnotationDiscoveryListener.java:48) 
    ... 107 more 
Caused by: java.lang.IllegalArgumentException: class=class com.alvazan.orm.impl.meta.data.MetaClassSingle has two fields that have @NoSqlId annotation. One of them may be in a superclass. The two fields are=private java.lang.String com.alvazan.orm.api.z8spi.meta.DboTableMeta.columnFamily and=private java.lang.String com.alvazan.orm.api.z8spi.meta.DboTableMeta.columnFamily 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.processIdFieldWorks(ScannerForClass.java:253) 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.inspectFieldImpl(ScannerForClass.java:220) 
    at com.alvazan.orm.impl.meta.scan.ScannerForClass.inspectField(ScannerForClass.java:207) 
    ... 111 more** 

Примечание:

---

Исходной проблема: В основном я получил следующие сообщения об ошибках при выполнении " запустить приложение»или„тест-приложение“на Grails:

| Loading Grails 2.2.1 
| Configuring classpath 
| Error SLF4J: Class path contains multiple SLF4J bindings. 
| Error SLF4J: Found binding in [jar:file:/home/saasbook/Dropbox/Projects/GrailsWorkSpace/gibb/lib/logback-classic-1.0.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] 
| Error SLF4J: Found binding in [jar:file:/home/saasbook/.grails/ivy-cache/org.grails/grails-plugin-log4j/jars/grails-plugin-log4j-2.2.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] 

приложение будет работать, но я хотел бы получить исключение PlayORM при попытке смыть тыс е объект в базу данных:

java.lang.IllegalArgumentException: Entity type=nosql.Transaction was not scanned and added to meta information on startup. It is either missing @NoSqlEntity annotation or it was not in list of scanned packages 

Примечание: класс «Transaction.java» имеет @NoSqlEntity и является частью пакета «NoSQL» вместе с «Persistance.java».

---

Первоначальный вопрос:

Мой Grails приложение производит сотни DEBUG o.c.g.g.i.s.PathMatchingResourcePatternResolver заявлений, когда я пытаюсь «запустить приложение» или «тест-приложение» или даже «чистые». Приложение работает от eclipse, но тестов нет.

Важная информация - я закажу приложение из локального репозитория git, и оригинальное приложение отлично работает на одном компьютере.

---

Ответ на комментарий: 1. Испытания просто не выполняется. 2. Я ничего не менял в настройках log4j. 3. После публикации этого вопроса я запустил оригинальную копию приложения (в другом каталоге) и создал тот же мусор, что и первый. Несмотря на то, что проблема заключается в том, что параметры настроек графиков сохраняются в ~/.grails/2.2.1/projects/{myProjectName}, но он сохраняется даже при одном «местоположении версии» приложения.

Answer 1

Этот вопрос был разрешен в автономном режиме, перейдя в ClassLoader из Transaction.class, так как grails играл в игры с загрузкой классов, а playorm был int he parent classloader, Transaction.class не был виден в загрузчике классов, загружавшем playorm.

Answer 2

У вас есть несколько вопросов, здесь все в одном вопросе (выглядит как 3 отдельных вопроса). Давайте сделаем одну из первых первых

Ошибка SLF4J: Путь к классу содержит несколько привязок SLF4J. | Ошибка SLF4J: Найдено привязка в [jar: файл: /home/saasbook/Dropbox/Projects/GrailsWorkSpace/gibb/lib/logback-classic-1.0.1.jar !/org/slf4j/impl/StaticLoggerBinder.class] | Ошибка SLF4J: найденное связывание в [jar: файл: /home/saasbook/.grails/ivy-cache/org.grails/grails-plugin-log4j/jars/grails-plugin-log4j-2.2.1.jar!/Org /slf4j/impl/StaticLoggerBinder.class]

Это просто потому, что пути SLF4J работает, вы не можете различные банки с StaticLoggerBinder.class. SLF4J может работать с log4j под ним OR commons OR jdk OR logback (который я предпочитаю больше всего и большинство людей предпочитают) ИЛИ ваш grails-plugin-log4j, который кажется нечетным. Это НИЖЕ.Выше, любые сторонние библиотеки, которые вы сосать, могут использовать log4j или общие или любую библиотеку, и до тех пор, пока у вас есть адаптеры SLF4j И удалите log4j.jar и commons.jar, все будут регистрироваться в любой системе ведения журнала, которую вы ставите ниже. В приведенном выше заявлении вы указали, что вам приходилось ниже провайдера logback-classic, который использовал бы файл logback.xml для регистрации конфигурации всех журналов (log4j, commons и т. Д.), А другой - grails-plugin-log4j, который имел бы собственный журнал файл конфигурации ... не logback.xml. Чтобы решить эту проблему, просто убедитесь, что у вас есть кусок того, который вы хотите ... мы используем logback one.

Следующая Два выпуска являются, вероятно, связано

java.lang.IllegalArgumentException: Тип Entity = nosql.Transaction был не сканируются и добавляется к метаинформации при запуске. Это либо отсутствует @NoSqlEntity аннотацию или его не было в списке проверяемых пакетов

Я пари на вопрос здесь загрузки классов. Если сканировать транзакцию (1) .class, но затем Transaction (2) .class передается в entityManager.put (tx), то вы получите этот сбой. Является ли Grails делать манипуляции байт-код на Transaction.java, как эта линия выглядит подозрительным ...

ERROR plugins.DefaultGrailsPlugin - Cannot generate controller logic for scaffolded class class nosql.Transaction. It is not a domain class! 

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

Answer 3

нормально, поэтому первый вопрос по проблеме classlaoding содержит специальные журналы для этой проблемы, которые идут в прямом режиме, только если включена регистрация уровня отладки. Он фиксирует, как он попал в этот код дважды. Один интересный кусок кода в ScannerForClass.processIdFieldWorks, в котором оно существует

if(field.equals(existingField) && log.isWarnEnabled()) 

и ваш код должен был принять этот путь, но не сделал. Возможно, вы не регистрируете журналы предупреждений или конфигурацию из этой привязки, которую вы используете для SLF4j, не делает ее там soooooo .... Я только что проверил изменение в playorm, чтобы удалить это. Если ваше поле не равно существующемуField на основе toStrings, то это определенно проблема с загрузкой классов, и я добавлю больше журналов, чтобы помочь в определении того, как этот класс загружается дважды.

Убедитесь, что вы также регистрируетесь на уровне отладки, поэтому он не регистрирует нуль в качестве трассировки стека первого вызова. (В основном два вызова на DboTableMeta произошли в этом методе, который никогда не должен происходить, поскольку существует только одно поле с @NoSqlId .... хорошо, только один допускается)

спасибо, Dean

Answer 4

Для выпуска

java.lang.IllegalArgumentException: Entity type=nosql.Transaction was not scanned and added to meta information on startup. It is either missing @NoSqlEntity annotation or it was not in list of scanned packages 

причиной может быть то, что, нет nosql.Persistence класс в вашем пути к классам. См. Соответствующие часто задаваемые вопросы по адресу http://buffalosw.com/wiki/FAQ/