Sven Haiges of grails podcast fame has created a Groovy/Grails/Griffon tweet aggregator that allows users to "re-tweet" important tweets, providing a community-based, self-organizing tweet prioritizing tweeting community (Getting dizzy. I should tweet about that.)
Check out http://www.groovytweets.org/.
Not satisfied with this, Sven created a nice "Headline Animator" that you can place on any html page to view the "important" tweets. This is one of three variations:
Danke
Showing posts with label groovy. Show all posts
Showing posts with label groovy. Show all posts
Saturday 24 August 2013
Thursday 22 August 2013
Top Most What is Groovy?
What is Groovy? Besides being music-inspired slang from the 1960's, Groovy is, in my view, the "next big thing" for the Java platform.
Why, you may ask? Here are a few reasons:
At this point, Groovy and Grails look like excellent bets for future development.
Why, you may ask? Here are a few reasons:
- Groovy is backward-compatible with Java, which translates to real business value.
- Groovy is designed to allow developers to be more productive, which also adds real business value.
- Groovy has become wildly popular in the recent past.Recent polls I've seen place Groovy as the most desired language by developers. In the open source world this fact is highly predictive.
- Ruby in the lead if you go by job postings, and Ruby is an excellent language. However Java developers must learn an entirely new syntax. Groovy is based on Java syntax, making it an easier transition for legacy Java developers.
- JRuby can run on the Java platform. However Groovy is built on top of Java and provides access to all the familiar Java api's. In fact Groovy enhances the Java object model, so in reality you are running not only on the Java platform, but you are running on Java standard classes.
- Groovy implements all the popular language constructs from Ruby, Smalltalk, Python and others, making it an excellent choice for the enterprise.
- New features that show up in Ruby or Groovy are quickly implemented in each other language.
- Java is widely perceived to be near sunsetting. Any language can tolerate only so many enhancements until it acquires a reputation of feature bloat.
- Groovy improves on Java. Syntactically, Groovy is clearer and more concise. And Groovy eliminates some of the the most common Java bugs.
- Grails, a popular application framework for Groovy, leverages RoR's "convention over configuration" approach, which further reduces the code developers need to write.
- During the last 12 months, downloads of Grails have grown from 7,000 to 70,000 per month.
- Groovy is 100% object-orientated, leaving Java compromises in the past forever.
- Groovy and Grails are production ready now, and are showing up in more and more web sites.
At this point, Groovy and Grails look like excellent bets for future development.
Labels:
future state,
grails,
groovy
Top Most JAMon plugin for Grails: Part 4 of 4
In this series we completed steps 1-4 of our task list:
Create a package structure under grails-app/conf. I used org/grails/plugins/filters. Create a file named JamonFilters and add the following code:
This code calls JAMon methods to start and stop timings. Note the variable skipControllers. This allows users of the plugin to easily define a list of controllers NOT to monitor by adding the variable
jamon.controllersToExclude to groovy.config.
This is all you need to do! Grails will add this filter to the application when you install the plugin.
To allow users to provide additional customizations to the plugin, we document some configuration settings they can set, and then access those settings in our plugin. For example, in the application's Config.groovy class, let's allow users to specify the following:
These settings will allow users to turn off monitoring for Controllers or Services, and specify services NOT to monitor as well as additional Spring beans classes to include.
To access these values in our JamonGrailsPlugin, we'll import:
To perform a safe test on a boolean value we can use the following code to default to true when the user does not specify a value:
Put together, the code now looks like this:
By using this logic we can allow users to easily customize the behavior of our jamon plugin.
The final step is to deploy your plugin. Type "grails package-plugin" in the root of your plugin project and Grails will create a .zip file. Then go to your Grails application and type "grails install-plugin path-to-your-zip-file", and you are ready to go.
Deploy the jamon.war that comes with the JAMon distribution to your web server then point your browser to /jamon/menu.jsp to view the results. Viola!
I hope you enjoyed this series. I'll add one more installment about testing your plugin when I have the chance. Meanwhile, have fun!
- Add jamon.jar to the application classpath
- Use JAMon's datasource proxy to monitor SQL
- Implement the JAMonServletFilter to monitor page hits
- Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
- Add a Spring filter to monitor Grails controllers
Create a package structure under grails-app/conf. I used org/grails/plugins/filters. Create a file named JamonFilters and add the following code:
package org.grails.plugins.filters
import com.jamonapi.MonitorFactory
import com.jamonapi.Monitor
import org.codehaus.groovy.grails.commons.ConfigurationHolder
/**
* @author eric weimer
*/
class JamonFilters {
Monitor monitor, viewMonitor, previewMonitor
def skipControllers = (ConfigurationHolder.config.jamon.controllersToExclude)? ConfigurationHolder.config.jamon.controllersToExclude: []
def filters = {
monitorController(controller: "*", action: "*") {
before = {
if (!(controllerName in skipControllers)) {
def monName = "Controller.${controllerName}.${actionName}"
monitor = MonitorFactory.start("${monName}")
previewMonitor = MonitorFactory.start("${monName}.noview")
}
true
}
after = {
if (previewMonitor) {
previewMonitor.stop()
def monName = "Controller.${controllerName}.${actionName}.view"
viewMonitor = MonitorFactory.start("${monName}")
}
true
}
afterView = {
if (monitor) monitor.stop()
if (viewMonitor) viewMonitor.stop()
true
}
}
}
}
This code calls JAMon methods to start and stop timings. Note the variable skipControllers. This allows users of the plugin to easily define a list of controllers NOT to monitor by adding the variable
jamon.controllersToExclude to groovy.config.
This is all you need to do! Grails will add this filter to the application when you install the plugin.
To allow users to provide additional customizations to the plugin, we document some configuration settings they can set, and then access those settings in our plugin. For example, in the application's Config.groovy class, let's allow users to specify the following:
jamon.monitorControllers = true
jamon.monitorServices = true
jamon.servicesToExclude = ['consoleService']
jamon.controllersToExclude = []
jamon.additionalBeans = ['com.eweimer.terrapin.util.MediaAccess','com.eweimer.terrapin.util.Key']
These settings will allow users to turn off monitoring for Controllers or Services, and specify services NOT to monitor as well as additional Spring beans classes to include.
To access these values in our JamonGrailsPlugin, we'll import:
import org.codehaus.groovy.grails.commons.ConfigurationHolder
To perform a safe test on a boolean value we can use the following code to default to true when the user does not specify a value:
def skipServices = application.config.jamon.servicesToExclude ?: []
Put together, the code now looks like this:
def monBeanNames = []
def skipServices = application.config.jamon.servicesToExclude ?: []
if (application.config.jamon.monitorServices ?: true) {
monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }
monBeanNames -= skipServices
}
if (application.config.jamon.additionalBeans) {
monBeanNames += application.config.jamon.additionalBeans
}
By using this logic we can allow users to easily customize the behavior of our jamon plugin.
The final step is to deploy your plugin. Type "grails package-plugin" in the root of your plugin project and Grails will create a .zip file. Then go to your Grails application and type "grails install-plugin path-to-your-zip-file", and you are ready to go.
Deploy the jamon.war that comes with the JAMon distribution to your web server then point your browser to /jamon/menu.jsp to view the results. Viola!
I hope you enjoyed this series. I'll add one more installment about testing your plugin when I have the chance. Meanwhile, have fun!
Labels:
best practices,
Flex,
grails,
groovy,
JAMon,
Java,
logging,
performance
Top Most JAMon plugin for Grails: Part 3 of 4
In this series we completed steps 1-3 of:
We'll add this to the doWithSpring closure. First we'll define a jamonInterceptor bean. It accepts a prefix attribute, which can be set to anything you like:
Next we need to get a list of beans to intercept. Service class beans are named by the class name with the first character set to lower case. Grails provides a list of service classes via the application object:
Finally we use Springs BeanNameAutoProxyCreator to add the jamon interceptor to the service classes:
Put it all together, it looks like this:
In part 4 of this series, we'll complete task #5 and deploy our JAMon plugin.
- Add jamon.jar to the application classpath
- Use JAMon's datasource proxy to monitor SQL
- Implement the JAMonServletFilter to monitor page hits
- Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
- Add a Spring filter to monitor Grails controllers.
We'll add this to the doWithSpring closure. First we'll define a jamonInterceptor bean. It accepts a prefix attribute, which can be set to anything you like:
def doWithSpring = {
jamonInterceptor( org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor, true, true ) {
prefix="Class."
}
}
def monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }
if (monBeanNames) {
autoProxyCreator( org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator ) {
proxyTargetClass="true"
interceptorNames=["jamonInterceptor"]
beanNames=monBeanNames as String[]
}
}
Put it all together, it looks like this:
def doWithSpring = {
def monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }
if (monBeanNames) {
jamonInterceptor(org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor, true, true) {
prefix="Class."
}
autoProxyCreator(org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator) {
proxyTargetClass="true"
interceptorNames=["jamonInterceptor"]
beanNames=monBeanNames as String[]
}
}
In part 4 of this series, we'll complete task #5 and deploy our JAMon plugin.
Labels:
best practices,
Flex,
grails,
groovy,
JAMon,
Java,
logging,
performance
Top Most JAMon plugin for Grails: Part 2 of 4
In part 1 we discussed four tasks needed to create a JAMon plugin. The first task was completed simply by adding jamon.jar to our plugin's lib folder. To review, the steps are:
JamonGrailsPlugin.groovy comes with a series of closures pre-defined. To change the datasource we add code to the doWithSpring closure. This closure allows you to update your Spring configuration.
We need to change the driverClassName to "com.jamonapi.proxy.JAMonDriver" and alter the url by adding "jamon:" after "jdbc:" and appending a parameter named "jamonrealdriver".
First lets add an import:
Then code the closure:
Step 3 is "implement the JAMonServletFilter to monitor page hits."
The doWithWebDescriptor closure will allow us to add our filter to the application. We need to append to both the <filter> and <filter-mapping> sections. Note that this is typical Grails builder code. The 'filter-mapping' node needs to be in quotes due to the hyphen in it's name:
In part 3 we'll move on to step #4.
- Add jamon.jar to the application classpath
- Use JAMon's datasource proxy to monitor SQL
- Implement the JAMonServletFilter to monitor page hits
- Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
- Add a Spring filter to monitor Grails controllers.
JamonGrailsPlugin.groovy comes with a series of closures pre-defined. To change the datasource we add code to the doWithSpring closure. This closure allows you to update your Spring configuration.
We need to change the driverClassName to "com.jamonapi.proxy.JAMonDriver" and alter the url by adding "jamon:" after "jdbc:" and appending a parameter named "jamonrealdriver".
First lets add an import:
import javax.sql.DataSource
def doWithSpring = {
def config = application.config
def orgUrl = config.dataSource.url
def driverClassName = config.dataSource.driverClassName
String appendUrl = (orgUrl.contains('?')? '&': '?') + 'jamonrealdriver=' + driverClassName
if (orgUrl.contains("oracle:")) appendUrl = 'jamonrealdriver=' + driverClassName
def url = orgUrl.replace("jdbc:","jdbc:jamon:") + appendUrl
config.dataSource.url = url
config.dataSource.driverClassName = "com.jamonapi.proxy.JAMonDriver"
}
Step 3 is "implement the JAMonServletFilter to monitor page hits."
The doWithWebDescriptor closure will allow us to add our filter to the application. We need to append to both the <filter> and <filter-mapping> sections. Note that this is typical Grails builder code. The 'filter-mapping' node needs to be in quotes due to the hyphen in it's name:
def doWithWebDescriptor = { webXml ->
def filters = webXml.filter
filters + {
filter {
'filter-name'("jAMonServletFilter")
'filter-class'("com.jamonapi.http.JAMonServletFilter")
}
}
def filterMappings = webXml.'filter-mapping'
filterMappings + {
'filter-mapping' {
'filter-name'("jAMonServletFilter")
'url-pattern'("/*")
}
}
}
}
Labels:
best practices,
Flex,
grails,
groovy,
JAMon,
Java,
logging,
performance
Top Most Jamon plugin for Grails: Part 1 of 4
JAMon is a popular, flexible, lightweight open source Java performance monitor. I won't cover all the features here, but in short JAMon can monitor performance, memory, number of users, basically any quantity you can access in Java.
To view the statistics JAMon provides a WAR file that you can deploy to your server along with your application. The war provides a set of JSP pages allowing you to view and export the data you are monitoring.
Another option is to incorporate the WAR into your application. It requires a little more work but you can enhance it to your hearts content.
Adding JAMon to Grails is really quite simple. What required some time was to experiment with the different methods JAMon can be inserted into your application. I prefer automation over hard-coded solutions.
Here are the tasks needed to get JAMon set up with an initial set of monitors:
I won't go into all the details regarding plugins. Good references are available here, here and here.
Fist download the JAMon distribution and unzip it.
Assuming you have a target application, let's assume you'll be creating your plugin in the same workspace (i.e. directory). Open a command prompt in that folder and type:
grails create-plugin jamon
If you've never created a plugin before you'll notice that Grails creates a typical Grails application with one additional file in the top directory: JamonGrailsPlugin.groovy.
This file is where we'll be doing most of the work.
To complete task #1 (add jamon.jar to the classpath), simple copy jamon.jar to jamon/lib. When an application installs the plugin, Grails will add jamon.jar to the classpath. That's all you need to do!
Next time I'll show how to implement the remaining tasks. Stay tuned.
To view the statistics JAMon provides a WAR file that you can deploy to your server along with your application. The war provides a set of JSP pages allowing you to view and export the data you are monitoring.
Another option is to incorporate the WAR into your application. It requires a little more work but you can enhance it to your hearts content.
Adding JAMon to Grails is really quite simple. What required some time was to experiment with the different methods JAMon can be inserted into your application. I prefer automation over hard-coded solutions.
Here are the tasks needed to get JAMon set up with an initial set of monitors:
- Add jamon.jar to the application classpath
- Use JAMon's datasource proxy to monitor SQL
- Implement the JAMonServletFilter to monitor page hits
- Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
- Add a Spring filter to monitor Grails controllers.
I won't go into all the details regarding plugins. Good references are available here, here and here.
Fist download the JAMon distribution and unzip it.
Assuming you have a target application, let's assume you'll be creating your plugin in the same workspace (i.e. directory). Open a command prompt in that folder and type:
grails create-plugin jamon
If you've never created a plugin before you'll notice that Grails creates a typical Grails application with one additional file in the top directory: JamonGrailsPlugin.groovy.
This file is where we'll be doing most of the work.
To complete task #1 (add jamon.jar to the classpath), simple copy jamon.jar to jamon/lib. When an application installs the plugin, Grails will add jamon.jar to the classpath. That's all you need to do!
Next time I'll show how to implement the remaining tasks. Stay tuned.
Labels:
best practices,
Flex,
grails,
groovy,
JAMon,
Java,
logging,
performance
Tuesday 20 August 2013
Top Most JAMon
Years ago I discovered a little gem in the world of a free and open source software: JAMon.
Still in use today, JAMon's mind-numbingly simple API provides a wealth of value for minimal effort. JAMon has now spawned competing products, each with its unique pros and cons.
JAMon is called a lightweight monitor. This may disappoint those who prefer large, feature-filled enterprise level commercial products, but the reality is JAMon delivers most of the data you need with minimal impact on performance. I would never consider developing a Java application without JAMon or some other monitoring solution. (JAMon is available for other languages as well.)
Best of all, you can have JAMon up and running in a few hours (or less)!
JAMon excels at timing code execution. Without any code changes you can configure JAMon to monitor SQL, method calls (via Spring AOP), as well as application entry and exit points.
In addition to execution time, JAMon allows you to monitor ANY data that can be expressed numerically. Common usage includes the number of users by hour of the day (to find usage peaks), simultaneous users, memory, heap size, session size, # of active sessions, and so on.
JAMon accumulates statistics rather than details which allows it to minimize its memory footprint. As it turns out, that is an excellent comprimise. JAMon keeps track of the number of invocations, min, max, average and standard deviation, as well as the min, max and average number of simultaneous executions, which is great for bottleneck analysis.
Although criticized for its inability to save statistics to a persistent store, you can do so with a little work if needed. You can persist statistics to a database, log file, expose them via JMX, etc.
You can configure JAMon start and stop monitoring dynamically. JAMon is typically measured at less than one percent overhead while turned on, and much less when turned off.
So if you have no monitoring (or your monitoring solution cannot be run in production), try JAMon or one of it's competitors. Documentation is a bit on the light side but there are plenty of examples on the Web.
And if you are a Grails developer, look for my posts about how to create a simple plugin to enable JAMon in your Grails applications.
Still in use today, JAMon's mind-numbingly simple API provides a wealth of value for minimal effort. JAMon has now spawned competing products, each with its unique pros and cons.
JAMon is called a lightweight monitor. This may disappoint those who prefer large, feature-filled enterprise level commercial products, but the reality is JAMon delivers most of the data you need with minimal impact on performance. I would never consider developing a Java application without JAMon or some other monitoring solution. (JAMon is available for other languages as well.)
Best of all, you can have JAMon up and running in a few hours (or less)!
JAMon excels at timing code execution. Without any code changes you can configure JAMon to monitor SQL, method calls (via Spring AOP), as well as application entry and exit points.
In addition to execution time, JAMon allows you to monitor ANY data that can be expressed numerically. Common usage includes the number of users by hour of the day (to find usage peaks), simultaneous users, memory, heap size, session size, # of active sessions, and so on.
JAMon accumulates statistics rather than details which allows it to minimize its memory footprint. As it turns out, that is an excellent comprimise. JAMon keeps track of the number of invocations, min, max, average and standard deviation, as well as the min, max and average number of simultaneous executions, which is great for bottleneck analysis.
Although criticized for its inability to save statistics to a persistent store, you can do so with a little work if needed. You can persist statistics to a database, log file, expose them via JMX, etc.
You can configure JAMon start and stop monitoring dynamically. JAMon is typically measured at less than one percent overhead while turned on, and much less when turned off.
So if you have no monitoring (or your monitoring solution cannot be run in production), try JAMon or one of it's competitors. Documentation is a bit on the light side but there are plenty of examples on the Web.
And if you are a Grails developer, look for my posts about how to create a simple plugin to enable JAMon in your Grails applications.
Labels:
best practices,
Flex,
grails,
groovy,
JAMon,
Java,
logging,
performance
Friday 16 August 2013
Top Most The problem with Java Primitives
As a long time Java user I have developed a love for the language.
At least until I found Groovy. Let me explain...
Smalltalk enjoyed a surge of popularity in the early 1990's when the "deep thinkers" of the industry proclaimed OO as the next big thing. However Smalltalk got stuck with a reputation of being "too slow".
When Java was designed in the mid 1990's it utilized primitives like int, char, float, etc. for performance. But if you think about it, here we have a mostly object-orientated language, where all comparison operators (>, <, ==, etc.) make sense with primitives, not objects!
Groovy designers, on the other hand, realized compiler technology and modern hardware utilize objects with excellent performance. However that leads to a quandary: how do we include operators in a way that makes sense?
The answer is operator overloading. But isn't operator overloading a bad thing? Didn't we learn that from C++?
Well, operator overloading can certainly be abused, but it is a natural way to allow operators to work in a fully object-orientated language.
Examine the following Groovy code:
public Boolean max(Integer i1, Integer i1) {
(i1 > i2)? i1 : i2
}
Even though i1 and i2 are objects of type Integer, this code works as expected. Why? Groovy overloads the '>' operator to call the compareTo() method. For integers, this works since Groovy has added the compareTo method to make Integers work as expected.
You see this all over the Groovy language. Instead of having to memorize Java's idiosynchronicies, Groovy works in an intuitive manner. Much like the Unix's RLS (Rule of Least Surprise), Groovy does what you expect.
Now take what is agruably the most common Java bug: comparing two String objects with '=='. Not only does it compile cleanly but it fails intermittenly, which is the hardest type of failure to cure. Yet it looks fine, passes code reviews, and makes it to production systems all too often. Even experienced Java developers miss it.
In Groovy, it just works. Groovy calls equals() when you use the '==' syntax. So now we have a language that not only is backward compatible with Java, but fixes common Java bugs!
All I can say is "Groovy".
At least until I found Groovy. Let me explain...
Smalltalk enjoyed a surge of popularity in the early 1990's when the "deep thinkers" of the industry proclaimed OO as the next big thing. However Smalltalk got stuck with a reputation of being "too slow".
When Java was designed in the mid 1990's it utilized primitives like int, char, float, etc. for performance. But if you think about it, here we have a mostly object-orientated language, where all comparison operators (>, <, ==, etc.) make sense with primitives, not objects!
Groovy designers, on the other hand, realized compiler technology and modern hardware utilize objects with excellent performance. However that leads to a quandary: how do we include operators in a way that makes sense?
The answer is operator overloading. But isn't operator overloading a bad thing? Didn't we learn that from C++?
Well, operator overloading can certainly be abused, but it is a natural way to allow operators to work in a fully object-orientated language.
Examine the following Groovy code:
public Boolean max(Integer i1, Integer i1) {
(i1 > i2)? i1 : i2
}
Even though i1 and i2 are objects of type Integer, this code works as expected. Why? Groovy overloads the '>' operator to call the compareTo() method. For integers, this works since Groovy has added the compareTo method to make Integers work as expected.
You see this all over the Groovy language. Instead of having to memorize Java's idiosynchronicies, Groovy works in an intuitive manner. Much like the Unix's RLS (Rule of Least Surprise), Groovy does what you expect.
Now take what is agruably the most common Java bug: comparing two String objects with '=='. Not only does it compile cleanly but it fails intermittenly, which is the hardest type of failure to cure. Yet it looks fine, passes code reviews, and makes it to production systems all too often. Even experienced Java developers miss it.
In Groovy, it just works. Groovy calls equals() when you use the '==' syntax. So now we have a language that not only is backward compatible with Java, but fixes common Java bugs!
All I can say is "Groovy".
Wednesday 14 August 2013
Top Most Testing the Grails JAMon Plugin
Previously I wrote about creating a JAMon plugin for Grails. Today I'll add some tests.
Since a plugin is a Grails application, you should add tests to your plugin project. Let's begin with opening a command window in the plugin project (jamon) and creating a test class:
Now we edit the class Grails created. We find this class in jamon\test\integration\JamonGrailsPluginTests.groovy.
First we see Grails creates a class that extends GrailsUnitTestCase. Since this is an integration test, we'll change it to extend GroovyTestCase instead. Let's add a few handy imports as well:
I'll add a couple variables for brevity sake:
Next we'll add the boiler plate setUp and tearDown methods. I like AgileDox naming so I'll override getName() as well:
This first test will be to verify the dataSources have been updated with the jamon proxy:
We make use of the Spring method getBeanNamesForType() to get all beans subclassed from DataSource, then simply test the attributes we attempted to set.
To verify that jamon is configured in the Spring context, we need a class in the plugin, such as a service class, to verify it is included in autoProxyCreatorBean. We can add a service by the grails command 'grails create-service jamonTest'. Of course we do not want the class added to our target applications, so we add the classname to the pluginExcludes variable in JamonGrailsPlugin:
Now we can code out test:
The remaining tests can be coded in a similar fashion. It is a good idea to include tests for all the plugin behaviours as well as any bugs that creep up over time.
That is it for the JAMon series. Hope these articles saved you some time. Your comments are encouraged!
Since a plugin is a Grails application, you should add tests to your plugin project. Let's begin with opening a command window in the plugin project (jamon) and creating a test class:
grails create-integration-test JamonGrailsPlugin
Now we edit the class Grails created. We find this class in jamon\test\integration\JamonGrailsPluginTests.groovy.
First we see Grails creates a class that extends GrailsUnitTestCase. Since this is an integration test, we'll change it to extend GroovyTestCase instead. Let's add a few handy imports as well:
import grails.test.*
import org.codehaus.groovy.grails.commons.ApplicationHolder
import org.codehaus.groovy.grails.commons.GrailsApplication
import javax.sql.DataSource
class JamonGrailsPluginTests extends GroovyTestCase {
I'll add a couple variables for brevity sake:
def app = ApplicationHolder.application
def ctx = app.mainContext
Next we'll add the boiler plate setUp and tearDown methods. I like AgileDox naming so I'll override getName() as well:
protected void setUp() {
super.setUp()
}
protected void tearDown() {
super.tearDown()
}
public String getName() {
return super.getName().substring(4).replaceAll("([A-Z])", " \$1").toLowerCase();
}
This first test will be to verify the dataSources have been updated with the jamon proxy:
void testDataSourcesAreJamonEnabled() {
ctx.getBeanNamesForType(DataSource).each{ beanName ->
def bean = ctx.getBean( beanName )
assertEquals "com.jamonapi.proxy.JAMonDriver", bean.driverClassName
assert bean.url.startsWith("jdbc:jamon:")
assert bean.url.contains('jamonrealdriver=')
}
}
We make use of the Spring method getBeanNamesForType() to get all beans subclassed from DataSource, then simply test the attributes we attempted to set.
To verify that jamon is configured in the Spring context, we need a class in the plugin, such as a service class, to verify it is included in autoProxyCreatorBean. We can add a service by the grails command 'grails create-service jamonTest'. Of course we do not want the class added to our target applications, so we add the classname to the pluginExcludes variable in JamonGrailsPlugin:
def pluginExcludes = [
"grails-app/views/error.gsp",
"grails-app/services/JamonTestService.groovy"
]
Now we can code out test:
void testJamonHasSpringAop() {
assertNotNull ctx.getBean("jamonInterceptor")
def autoProxyCreatorBean = ctx.getBean("autoProxyCreator")
assertNotNull autoProxyCreatorBean
assertArrayEquals (["jamonTestService"].toArray(), autoProxyCreatorBean.beanNames.toArray())
}
The remaining tests can be coded in a similar fashion. It is a good idea to include tests for all the plugin behaviours as well as any bugs that creep up over time.
That is it for the JAMon series. Hope these articles saved you some time. Your comments are encouraged!
Labels:
best practices,
grails,
groovy,
JAMon,
testing
Friday 9 August 2013
Top Most Chicago Groovy User Group
Tomorrow I am presenting an intro to Groovy and Grails at the Chicago Groovy User Group monthly meeting.
As usual I have a bad cold and am dead tired. However I'll give it my best effort since the organizers are all great guys and have put a lot of effort into getting this group off the ground.
There will be free pizza and drinks. Best of all, raffle prizes!
Slides of the talk are available in pptx format as well as pdf.
As usual I have a bad cold and am dead tired. However I'll give it my best effort since the organizers are all great guys and have put a lot of effort into getting this group off the ground.
There will be free pizza and drinks. Best of all, raffle prizes!
Slides of the talk are available in pptx format as well as pdf.
Top Most Chicago Groovy User Group - March 2010
I am giving a talk on "recipes" at the March 9, 2010 Chicago Groovy User Group (www.cgug.org).
The Powerpoint may be found here.
The Powerpoint may be found here.
Wednesday 7 August 2013
Top Most Syntactic Sugar
Syntactic sugar is a colorful expression that has been popping up in tech circles for the last few years. There is even a Wikipedia page for it.
Java contains a bit of syntactic sugar. All objects in Java are created through calls to the object model except one: String. Strings can be created directly through Java syntax.
In Java we can create a String through the object model by calling a constructor:
String name = new String ("eduardo");
Or we can use this bit of "syntactic sugar":
String name = "eduardo";
As you can see, syntactic sugar gives us two things: clarity and conciseness. It usually does not add any new functionality.
Groovy expands on syntactic sugar. This allows Groovy code to be expressive and concise. Multiply that by the thousands of lines of code a developer reads and it adds up to real productivity. (Of course, the time saved usually gets blown on things like writing blogs, etc.)
Take the following Groovy syntax:
(0..9).times {...}
Even if you've never seen Groovy syntax it is quite obvious this is iterating from o..9. This is arguably clearer than the Java alternative:
for (int i = 0; i < 10; i++) { ... } Groovy makes great use of Syntactic sugar, allowing developers to express their intentions in a more concise and clear manner then legacy Java. Java simply cannot add many next generation features. Java is hampered by the need to be backwards compatible and it's lack of full object orientation. To remain competitive in the future we need to turn to a new language. My money is on Groovy.
Java contains a bit of syntactic sugar. All objects in Java are created through calls to the object model except one: String. Strings can be created directly through Java syntax.
In Java we can create a String through the object model by calling a constructor:
String name = new String ("eduardo");
Or we can use this bit of "syntactic sugar":
String name = "eduardo";
As you can see, syntactic sugar gives us two things: clarity and conciseness. It usually does not add any new functionality.
Groovy expands on syntactic sugar. This allows Groovy code to be expressive and concise. Multiply that by the thousands of lines of code a developer reads and it adds up to real productivity. (Of course, the time saved usually gets blown on things like writing blogs, etc.)
Take the following Groovy syntax:
(0..9).times {...}
Even if you've never seen Groovy syntax it is quite obvious this is iterating from o..9. This is arguably clearer than the Java alternative:
for (int i = 0; i < 10; i++) { ... } Groovy makes great use of Syntactic sugar, allowing developers to express their intentions in a more concise and clear manner then legacy Java. Java simply cannot add many next generation features. Java is hampered by the need to be backwards compatible and it's lack of full object orientation. To remain competitive in the future we need to turn to a new language. My money is on Groovy.
Labels:
future state,
grails,
groovy,
Java
Saturday 3 August 2013
Top Most Grails Logging
I am in the middle of a Grails/Flex project. One of the criteria involved with the selection of Grails was the large number of blogs, articles and documentation available.
The other criteria was, of course, improved productivity.
We have an aggressive deadline of eight weeks. Our customer chose the Drupal CMS for the site, but we had concerns about it's suitability and scalability. We ended up using Drupal for it's strengths, like FAQ's, blogs, etc. We selected Grails for the bulk of data handling and Flex for the front end. (No one does "eye candy" as well as Flex. Perhaps JavaFX some day, but today it is Flex.)
For the most part, Grails has grown so popular it has been easy finding solutions to common problems. However, one area lacking in advice is, oddly enough, basic logging.
So here is our logging configuration. We use four appenders, the console and three rolling files. The console is designed to make watching the application as painless as possible. Besides the usual Grails output, it displays only error level logging.
The three rolling file appendars contain error, debug and trace level logging respectively. The error log is great for quickly determining if any errors have occurred.
The debug log is excellent for researching issues not made obvious by the error log. The trace log adds Hibernate data values to the queries if you really need that level of detail.
So here it is, a working Grails 1.1 version logging configuration, straight from Config.groovy. As it turns out, the best source for learning about this is the documentation from the Grails web site.
I hope you find this useful:
The other criteria was, of course, improved productivity.
We have an aggressive deadline of eight weeks. Our customer chose the Drupal CMS for the site, but we had concerns about it's suitability and scalability. We ended up using Drupal for it's strengths, like FAQ's, blogs, etc. We selected Grails for the bulk of data handling and Flex for the front end. (No one does "eye candy" as well as Flex. Perhaps JavaFX some day, but today it is Flex.)
For the most part, Grails has grown so popular it has been easy finding solutions to common problems. However, one area lacking in advice is, oddly enough, basic logging.
So here is our logging configuration. We use four appenders, the console and three rolling files. The console is designed to make watching the application as painless as possible. Besides the usual Grails output, it displays only error level logging.
The three rolling file appendars contain error, debug and trace level logging respectively. The error log is great for quickly determining if any errors have occurred.
The debug log is excellent for researching issues not made obvious by the error log. The trace log adds Hibernate data values to the queries if you really need that level of detail.
So here it is, a working Grails 1.1 version logging configuration, straight from Config.groovy. As it turns out, the best source for learning about this is the documentation from the Grails web site.
I hope you find this useful:
log4j = {
appenders {
console name:'console', threshold:Level.ERROR,layout:pattern(conversionPattern: '%p %d{ISO8601} %c{4} %m%n')
rollingFile name:"rollingFileTrace", threshold:Level?TRACE, maxFileSize:1048576, file:logFile+'Trace?log', ayout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
rollingFile name:"rollingFileDebug", threshold:Level?DEBUG, axFileSize:1048576,file:logFile+'Debug.log', layout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
rollingFile name:"rollingFileError", threshold:Level.ERROR, axFileSize:1048576,file:logFile+'Error.log', layout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
}
error console, rollingFileDebug, rollingFileError, rollingFileTrace:
'org.codehaus.groovy.grails.web.servlet', // controllers
'org.codehaus.groovy.grails.web.pages', // GSP
'org.codehaus.groovy.grails.web.sitemesh', // layouts
'org.codehaus.groovy.grails."web.mapping.filter', // URL mapping
'org.codehaus.groovy.grails."web.mapping', // URL mapping
'org.codehaus.groovy.grails.commons', // core / classloading
'org.codehaus.groovy.grails.plugins', // plugins
'org.codehaus.groovy.grails.orm.hibernate', // hibernate integration
'org.springframework'
debug rollingFileDebug, rollingFileTrace:'org.hibernate',
'com.britetab',
'BootStrap',
'org.apache.ddlutils'
trace rollingFileTrace:'org.hibernate.SQL',
'org.hibernate.type',
'flex.messaging.services'
warn console,rollingFileDebug,rollingFileTrace:'org.mortbay.log',
'org.hibernate.tool.hbm2ddl'
root {
error 'console','rollingFileError','rollingFileDebug','rollingFileTrace'
additivity = true
}
}
Subscribe to:
Posts (Atom)
Labels
Core Java
programming
core java interview question
Core Java Faq's
Servlets
coding
database
jsp-servlet
spring
Java
linux
unix
interview questions
java investment bank
Web Services
Interview
investment bank
mysql
Senior java developer interviews
best practices
java collection tutorial
RMI
SQL
Eclipse
FIX protocol tutorial
tibco
J2EE
groovy
java questions
SCJP
grails
java 5 tutorial
jdbc
beginner
error and exception
Design Patterns
Java Programming Tutorials
fundamentals
general
object oriented programming
xml
Java Programs
Hibernate
Examples
Flex
JAMon
Java xml tutorial
logging
Jsp
Struts 2.0
Sybase and SQL Server
debugging
java interviews
performance
FIX Protocol interview questions
JUnit testing
WebSphere
date and time tutorial
experienced
java IO tutorial
java concurrency
thread
Ejb
Freshers Papers
IT Management
Java Exapmle
Java Script
SQL and database tutorial examples
Scwcd
ant tutorials
concurrency example and tutorial
future state
homework
java changes
java threading
tricky
Agile
Business of IT
Development
JSTL
Java JSON tutorial
Java multithreading Tutorials
PM
Scrum
data structure and algorithm
java puzzles
java tips
testing
tips
windows 8
5 way to create Singleton Object
Architect Interview Questions and Answers
Architecture
Architecure
Bluetooth server as swing application that searches bluetooth device in 10 meter circle and show all devices. You can send file to any bluetooth device.
C Programming
CIO
Callable Statement in Java
Circular dependency of Objects in Java
Comparable Example in Collection
Custom annotation in Java
Developer Interview
Divide and rule example in java
Drupal
Example of Singleton Pattern
FIX protocol
ForkJoin Example in Java 7
Get data from dynamic table with Java Script
Git
HTML and JavaScript
Health
Hello World TCP Client Server Networking Program
Hibernate Basics
Hibernate Interview Question Answer
J2EE Interview Question And Answers
J2ME GUI Program
JEE Interview QA
JMS interview question
Java J2EE Hibernate Spring Struts Interview Question
Java System Property
Java Threads
Manager
Portlets
Provident Fund
Read data from any file in same location and give the required result.
Reading Properties File in Java
Redpoint
Rest WebService Client
Rest Webservice Test
SAL join with ven diagram
SCP UNIX COMMAND
SSL
Singleton Pattern in Java
Spring Bean Initialization methods and their order
Spring Interview Questions
Struts
Struts 2.0 Basics
Struts 2.0 Design Pattern
Submit Html Form With Java Script On The Fly
Unix executable For Java Program
XOM DOM SAX
XP
books
computers
core java;
core java; object oriented programming
data structure; java investment bank;
design pattern
dtd
duplicate rows in table
get browser name with jquery
grails podcast
inner class
java beginners tutorial
java cache
java networking tutorial
java spring
java util; java collections; java questions
java.java1.5
linked list
mailto function with all browser
oracle database
oracle duplicate rows
orm
schema
social
spring mvc questions
struts
transaction
tricks
tweet
windows
xslt