4 messages in org.codehaus.groovy.userRe: [groovy-user] HQ gets more game b...| From | Sent On | Attachments |
|---|---|---|
| Jon Travis | 25 Mar 2008 09:39 | |
| Keith Thomas | 25 Mar 2008 09:44 | |
| Guillaume Laforge | 25 Mar 2008 09:49 | |
| Jon Travis | 25 Mar 2008 10:33 |
| Subject: | Re: [groovy-user] HQ gets more game by being Groovy! |
|---|---|
| From: | Jon Travis (jtra...@p00p.org) |
| Date: | 03/25/2008 10:33:45 AM |
| List: | org.codehaus.groovy.user |
I initially looked at using Grails for this task, but wasn't able to get it quite the way I wanted. Quite unfortunate, since Grails provides a lot of utilities that I would have liked to take advantage of.
Grails comes a bit heavyweight. It uses Spring (we would like to, but can't ATM), Hibernate, etc. Persistence is something we currently provide in our backend.
Hot redeployment of Grails plugins were self-contained webapps with their own web.xml. This wasn't acceptable for our setup. We'd like our plugins to have visibility into the parent classloaders, be redeployable in a few seconds, participate in our authentication and other filtering mechanisms, etc.
I'm sure much of this has changed over the past year, but at the time, this was the easiest and quickest for us to implement. Plus, it gave me great experience developing Groovy.
-- Jon
On Mar 25, 2008, at 9:45 AM, Keith Thomas wrote:
Thanks Jon, great information. Are you able to share the thought process behind writing your own plug-in framework rather than using Grails plug-in framework?
On Tue, Mar 25, 2008 at 9:40 AM, Jon Travis <jtra...@p00p.org> wrote: Ahoy, Groovy cats!
I wanted to drop a note, thanking the community and the Groovy developers for creating such a solid, important piece of software. It's enabled us to be very agile, adding new pluggable features to our Java app in minutes. I hope this letter inspires other Java based projects to consider adding Groovy to their arsenal.
We are using Groovy for a variety of things: - Creating pluggable UI screens and features - Providing web-services APIs - Templating emails sent in Alerts - Increasing visibility to diagnose issues in a running server - Giving admins the ability to script and automate HQ in an easy and obvious way
Our software (Hyperic HQ) is a very large project, able to monitor any software / hardware via a generic plugin infrastructure. This generic nature also means that our UI does not have specific screens for specific products. We've created a plugin framework (HQU) based on Groovy, which allows plugins to display entirely new screens, embedded within our application.. This means that we can now provide extremely deep, detailed information about MySQL, Apache, Cisco IOS, etc. in screens tailored exactly for that product. HQU provides a Rails/Grails style interaction between the HQ server and the plugins, providing maximum power, with minimum code.
We've used HQU to create our Alert Center, Event Center, Groovy Console, Nagios screens, and tonnes more. The code-rev time of working on a Groovy-based feature is a fraction of the time compared to compiling and redeploying Java changes. Time from change to reload is < 15 seconds.
On the web-services side, Groovy's XML integration is so seamless and easy, we are able to create interactions with JIRA or other RSS / XML based services in only a few lines. This productivity would not have been possible without the benefit of Groovy.
HQU also provides an API on top of our Java API which makes accessing our internal APIs more paletable. Since HQ was originally built on session beans, the API is generally not as object-oriented as we'd like and the APIs suffer from corosion. By using Categories and MetaClasses, we can give developers an obvious, intuitive toolkit.
Finally, we've added a Groovy Console to our administration section. This has proven to be invaluable when developing a feature (who needs to recompile to test HQL queries?), debugging a running instance, or performing advanced, scripted functions.
I'll be giving a HyperCAST on Wednesday (will be archived), discussing how Groovy fits into our development cycle.
HyperCAST information here: http://www.hyperic.com/demo/ hypercasts.html
HQU Plugins can also be viewed here: - hquplugins.org (development information) - http://support.hyperic.com/confluence/display/hypcomm/HQU+Forge (plugins)
-- Jon Travis Principal Engineer, Hyperic Inc.
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--------------------------------------------------------------------- To unsubscribe from this list, please visit: