понедельник, 22 июля 2013 г.
пятница, 19 июля 2013 г.
Solution for Grails/JDK 1.7.0_25 compatibility problem
The previously reported problem with Grails/JDK 1.7.0_25 compatibility
seems to be specific to OpenJDK. As soon as the one replaces OpenJDK
with Oracle JDK, error is gone and Grails applications could be started
again.
среда, 17 июля 2013 г.
Change in JDK 1.7.0_25 breaks all grails applications:
https://bugzilla.redhat.com/show_bug.cgi?id=976693
I just tried grails 2.2.3 - the problem is still not fixed, the application fails to start with an error message "Could not determine Hibernate dialect for database name [H2]".
Any workarounds suggesting to replace hibernate libraries don't work.
The following additional parameter allows to start grails:
grails -noreloading run-app
But hey, it's no fun to start in no-reloading mode! Oracle, but things back!
https://bugzilla.redhat.com/show_bug.cgi?id=976693
I just tried grails 2.2.3 - the problem is still not fixed, the application fails to start with an error message "Could not determine Hibernate dialect for database name [H2]".
Any workarounds suggesting to replace hibernate libraries don't work.
The following additional parameter allows to start grails:
grails -noreloading run-app
But hey, it's no fun to start in no-reloading mode! Oracle, but things back!
воскресенье, 14 июля 2013 г.
A happier, groovier way to parse RTF: apache_tika + XmlSlurper
I discovered a new way to parse RTF in java/groovy programs.
Consider the following sequence:
1. Instantiate XmlSlurper
2. Instantiate RTFParser (of Apache Tika)
3. Parse RTF (either file or string), passing XmlSlurper to RTFParser (such passing is possible, since RTFParser expects ContentHandler interface, which is implemented by XmlSlurper).
4. Traverse RTF content groovy-style: each, find, findAll, etc.
Example of code here:
https://gist.github.com/akhikhl/5993538
Consider the following sequence:
1. Instantiate XmlSlurper
2. Instantiate RTFParser (of Apache Tika)
3. Parse RTF (either file or string), passing XmlSlurper to RTFParser (such passing is possible, since RTFParser expects ContentHandler interface, which is implemented by XmlSlurper).
4. Traverse RTF content groovy-style: each, find, findAll, etc.
Example of code here:
https://gist.github.com/akhikhl/5993538
четверг, 11 июля 2013 г.
Programmatic configuration of slf4j/logback
Now I have experience with programmatic configuration of slf4j/logback.
Task
A program must open separate log file for each processed input file.
Solution for task
Instead of configuring logback via xml, the one needs to “manually” instantiate encoders, appenders and loggers, then configure and link them together.
Caveat 1
Logback goes crazy on attempt to share encoder (i.e. PatternLayoutEncoder) between appenders.
Solution for caveat 1
Create separate encoder for each appender.
Caveat 2
Logback refuses to log anything, if encoders and appenders are not associated with logging context.
Solution for caveat 2
Call setContext on each encoder and appender, passing LoggerFactory as a parameter.
Caveat 3
Logback refuses to log anything, if encoders and appenders are not started.
Solution for caveat 3
encoders and appenders need to be started in the correct order, i.e. first encoders, then appenders.
Caveat 4
RollingPolicy objects (i.e. TimeBasedRollingPolicy) produce strange error messages like “date format not recognized”, when they are not attached to the same context as appender.
Solutin for caveat 4
call setContext on RollingPolicy same way as on encoders and appenders.
Here is working example of “manual” logback configuration:
https://gist.github.com/akhikhl/5977126
My conclusion: logback is much easier to configure via XML. “Manual” configuration is rather tedious task and should be avoided, unless it is dictated by project needs.
Task
A program must open separate log file for each processed input file.
Solution for task
Instead of configuring logback via xml, the one needs to “manually” instantiate encoders, appenders and loggers, then configure and link them together.
Caveat 1
Logback goes crazy on attempt to share encoder (i.e. PatternLayoutEncoder) between appenders.
Solution for caveat 1
Create separate encoder for each appender.
Caveat 2
Logback refuses to log anything, if encoders and appenders are not associated with logging context.
Solution for caveat 2
Call setContext on each encoder and appender, passing LoggerFactory as a parameter.
Caveat 3
Logback refuses to log anything, if encoders and appenders are not started.
Solution for caveat 3
encoders and appenders need to be started in the correct order, i.e. first encoders, then appenders.
Caveat 4
RollingPolicy objects (i.e. TimeBasedRollingPolicy) produce strange error messages like “date format not recognized”, when they are not attached to the same context as appender.
Solutin for caveat 4
call setContext on RollingPolicy same way as on encoders and appenders.
Here is working example of “manual” logback configuration:
https://gist.github.com/akhikhl/5977126
My conclusion: logback is much easier to configure via XML. “Manual” configuration is rather tedious task and should be avoided, unless it is dictated by project needs.
среда, 10 июля 2013 г.
Disappointment with groovy/XmlSlurper
Greatest
disappointment with groovy/XmlSlurper: it does not read/interpret XML
comments. Quite critical for massive XML processing/transformations,
when it is necessary to keep change delta to minimum.
In the last
project I had to recede to JDOM2 - it reads, interprets and writes XML
comments without problems. Sad, volume of code doubles compared to
XmlSlurper.
пятница, 5 июля 2013 г.
groovy XmlParser and XmlSlurper
I am absolutely astonished by functionality of groovy classes XmlParser and XmlSlurper. The both are similar to each other, with one important difference: XmlParser is more DOM-like (all data in memory), while XmlSlurper is more SAX-like (data parsing delayed until needed).
The most charming thing is how both work together with closures, regexps and collection methods. I am seriously thinking about shifting all XML-specific code to these facilities.
http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlParser
http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper
Подписаться на:
Сообщения (Atom)
