Bei der Deklaration einer Domänen-Klasse in Groovy wird auf die Bean-Notation für Variablen (Variable deklariert als private, zusätzlich Getter und Setter) verzichtet. Stattdessen werden sogenannte Properties definiert, die durch Groovy intern in Java-Beans umgewandelt werden.
[groovy]
class MyTest {
Long id
String val1, val2
}
[/groovy]
Oftmals ist es nötig, die Liste der Properties auszulesen, etwa um ein Objekt in ein anderes zu mappen. Hierfür bietet Groovy die Methode getProperties():
[groovy]
def x = new MyTest()
x.properties.each { key, value ->
println “Property ${key}. ${value}”
}
[/groovy]

Hier tauchen aber plötzlich Properties auf, die in MyType gar nicht definiert wurden, wie version, class, metaClass, constraints! Grails Magic, hier wurden durch das Grails-Framework weitere Properties hinzugefügt!

Wie kommt man nun an die Liste nur der selbst definierten Properties? Die Antwort liegt bei den persistentProperties, die in der Klasse liegen. Diese erreicht man über die DefaultGrailsDomainClass.
[groovy]
def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println “${it.name}”
}
[/groovy]
Et Voila: Die Liste der persistenten Properties, in aller Regel der selbstdefinierten.

Read Properties of a Grails Domain Class

With the declaration of a domain class in  Groovy it is done without a Bean-Notation for variables (variable declared as  private, furthermore Getter and Setter). Instead so called properties are defined which are changed internally into Java-Beans by Groovy
[groovy]
class MyTest {
Long id
String val1, val2
}
[/groovy]
It is often necessary to read out the list, for example to map an object into another. Therefore Groovy offers the methode getProperties():
[groovy]
def x = new MyTest()
x.properties.each { key, value ->
println “Property ${key}. ${value}”
}
[/groovy]

At this points properties suddenly appear which haven’t been defined like version, class, metaClass, constraints! Grails Magic, further properties have been added by the Grails-Framework!

So how do you get the list of the self defined properties only? The answer lies within the persistentProperties, which are within the class. You can reach it via DefaultGrailsDomainClass.
[groovy]
def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println “${it.name}”
}
[/groovy]
Et Voila: The list of persistent properties, usually the self defined.

Kurzanleitung:

• Aus Classloader-Gründen darf die Applikation nicht eine eigene log4j-xxx.jar beinhalten. Diese kann aus dem war-file entfernt werden durch folgenden Eintrag in BuildConfig.groovy:
  [groovy]
  grails.war.resources = { stagingDir ->
  delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
  delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
  }
  [/groovy]
  (Der Eintrag mit tomcat ist für das Thema hier nicht relevant, entfernt aber unnötige Klassen aus dem war-file.)
• Die Grails-Log4j-Konfiguration aus Config.groovy wird im JBoss nicht ausgewertet. Daher sind die Einträge in der JBoss-Log4j-Konfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml nachzuziehen.
  Beispiel für Controller:
  [xml]
  <category name=”grails.app.controller.MyController”>
  <priority value=”INFO”/>
  </category>
  [/xml]
  Man beachte auch das “grails.app.controller“-Präfix!
• Eine weitere Seltsamkeit ist, dass nach einem Undeploy oder Redeploy eines Grails-war-files das Logging des JBoss komplett beendet wird, d.h. absolut nichts mehr in die Logdatei geschrieben wird. Den Grund und eine saubere Lösung dafür habe ich noch nicht gefunden, aber als Workaround ist es möglich, ein touch auf ${JBOSS}/server/default/conf/jboss-log4j.xml auszuführen. Da diese Konfiguration regelmäßig eingelesen wird, erscheinen die Logmeldungen wieder.

Logging of Grails application in JBoss

Brief administration:

• Because of  Classloader reasons the application can not have an own  log4j-xxx.jar. It can be deleted from the war-file with the following entry in  BuildConfig.groovy:
  [groovy]
  grails.war.resources = { stagingDir ->
  delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
  delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
  }
  [/groovy]
  (The entry with tomcat is not relevant for this topic, but deletes unnecessary classes from the war-file.)
• The Grails-Log4j-configuration from Config.groovy is not evaluated in JBoss. Therefore the entries need to be moved in the JBoss-Log4j-onfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml.
  Example for Controller:
  [xml]
  <category name=”grails.app.controller.MyController”>
  <priority value=”INFO”/>
  </category>
  [/xml]
  Keep the “grails.app.controller“-Prefix in mind!
• Another oddity is that after an undeploy or redeploy of a Grails-war-file the logging of the JBoss will be completely closed,  which means that absolutely nothing is written in the log file. We haven’t found yet the reason and a clean solution for this problem, but as a Workaround it is possible to make a touch to ${JBOSS}/server/default/conf/jboss-log4j.xml. Because this configuration will be importet regularly the logging messages will reoccur.