Don't use those libraries - instead use the good old grails-xfire plugin. This guy just works out of the box with .NET 3.5 and 4.0. In C# just add a web reference and you're all set!
More on this topic soon - stay tuned!
Friday, December 31, 2010
Grails, WebServices and .NET interoperability
This is just a quick note for all those that have tried to interop between Grails and .NET using Apache CXF or Apache Axis2 and failed miserably:
Don't use those libraries - instead use the good old grails-xfire plugin. This guy just works out of the box with .NET 3.5 and 4.0. In C# just add a web reference and you're all set!
More on this topic soon - stay tuned!
Don't use those libraries - instead use the good old grails-xfire plugin. This guy just works out of the box with .NET 3.5 and 4.0. In C# just add a web reference and you're all set!
More on this topic soon - stay tuned!
Thursday, December 30, 2010
Running PHP applications on .NET
Continuing my good fortune in integration between completely different platforms I've tried to integrate some PHP interpreter/compiler called Phalanger 2.0 with existing PHP applications and run them on .NET using VWD server.
PhpBB 3.x
Well, it was no easy thing to do but I've got it to work. And let me tell you it works fast!
One thing to note is that PhpBB did not like the included MySQL connector and I've had to download this one and install it instead.
WordPress
Well, after I've gotten PhpBB to work using the right
However getting it to display anything is a nightmare on the internal VWD server because it does not support default documents. So everytime I wanted to display a page I've had to append some stupid parameters to the URL so that the part "index.php" would not get lost.
Others (phpMyAdmin, MediaWiki)
The docs here state that Phalanger 2.0 is perfectly capable of running those 2 applications but as practice has shown there was absolutely no way to bend them to .NET environment. Pity...
I'm going to check how things are with pure IIS and its capabilities for defining the default document :)
Stay tuned!
PhpBB 3.x
Well, it was no easy thing to do but I've got it to work. And let me tell you it works fast!
One thing to note is that PhpBB did not like the included MySQL connector and I've had to download this one and install it instead.
WordPress
Well, after I've gotten PhpBB to work using the right
web.config getting this guy to work was just a matter of minutes. However getting it to display anything is a nightmare on the internal VWD server because it does not support default documents. So everytime I wanted to display a page I've had to append some stupid parameters to the URL so that the part "index.php" would not get lost.
Others (phpMyAdmin, MediaWiki)
The docs here state that Phalanger 2.0 is perfectly capable of running those 2 applications but as practice has shown there was absolutely no way to bend them to .NET environment. Pity...
I'm going to check how things are with pure IIS and its capabilities for defining the default document :)
Stay tuned!
Compiling Groovy 1.7.6 with IKVM
If you'd like to see how to compile Groovy 1.7.6 under IKVM.NET take a look at this archive. It contains everything you need to be able to turn the groovy-all-1.7.6.jar (and its dependencies) into both an executable (that runs the console) and a library that can then be embedded into a .NET application.
Beware: This is a 27MB download so it's not a small thing.
groovy-1.7.6-net.zip
1. The first one occurs when compiling commons-logging-1.1.1.jar as it also requires LogKit which I was to lazy to collect and compile
2. The second one occurs while compiling Groovy itself as there are still some dependencies missing. They aren't however important enough to block the usage of compiled library and executable.
Let me know if you'll find this interesting and/or useful :)
Beware: This is a 27MB download so it's not a small thing.
groovy-1.7.6-net.zip
A note about the compilation process
Please note that there are some issues during 2 phases of the compilation:1. The first one occurs when compiling commons-logging-1.1.1.jar as it also requires LogKit which I was to lazy to collect and compile
2. The second one occurs while compiling Groovy itself as there are still some dependencies missing. They aren't however important enough to block the usage of compiled library and executable.
Let me know if you'll find this interesting and/or useful :)
Groovy scripting from C#
Well, after the last finding that the Groovy Console executes on IKVM.NET what must have followed was embedding of Groovy scripting capabilities in a C# application.
Here you can snatch the project along with everything needed to compile and run it (besides the .NET framework of course). Beware, it's a 19MB download (50MB+ after unzipping). I've created it using Visual C# Express 2010.
Have fun!
Here you can snatch the project along with everything needed to compile and run it (besides the .NET framework of course). Beware, it's a 19MB download (50MB+ after unzipping). I've created it using Visual C# Express 2010.
Have fun!
Groovy 1.7.6 under .NET
Well, I finally did it! It did require a huge leap of fate but it finally turned out possible: Groovy running on .NET using IKVM 0.44.0.5!
And not only running but also interoperating with .NET classes!
It's running extremely slow but stable enough to play around a bit with it.
Next step: using Groovy classes from .NET!
And not only running but also interoperating with .NET classes!
It's running extremely slow but stable enough to play around a bit with it.
Next step: using Groovy classes from .NET!
Wednesday, December 29, 2010
Grails, configuration and the logSql option
I've tried today to make the
After a previous success with changing the
However what did work was when I included not a ".properties" file but a ".groovy" file as the override configuration and then configured the
I've included the external configuration from the
That did the trick so I've tried to go one step further and completely reconfigure the
This is probably the best thing that ever happened to web application deployment :D This way you're able to completely reconfigure your application (even the most intimate things like bean properties if you so desire) and all that from as many configuration files as I want (just one works as well).
To utilize the new capabilities I've also reconfigured logging:
That's soooo cool that I can do that :) It helps me be in line with what the admin of our production environment demands.
And best of all: NO DAMN XML WHATSOEVER :) I love being a Grails developer :)
dataSource.logSql configurable from an external file so that after deployment I can decide if I want to see the SQL statements in logs or not.After a previous success with changing the
dataSource.url parameter in a properties file designated as an external configuration file I did exactly the same with the logSql option. It turned out not to work.However what did work was when I included not a ".properties" file but a ".groovy" file as the override configuration and then configured the
dataSource as follows:dataSource {
logSql = false // disable SQL statements logging
}I've included the external configuration from the
environments block like this:// set per-environment serverURL stem for creating absolute links
environments {
production {
grails.config.locations = [ "file:/etc/example/example-config.groovy" ]
grails.serverURL = "http://www.changeme.com"
}
...That did the trick so I've tried to go one step further and completely reconfigure the
dataSource that previously used an embedded HSQL database to use MySQL:dataSource {
logSql = false
driverClassName = 'com.mysql.jdbc.Driver'
dialect = 'org.hibernate.dialect.MySQL5InnoDBDialect'
dbCreate = 'update'
url = 'jdbc:mysql://127.0.0.1:3306/example'
username = 'root'
password = ....
}/var/lib/tomcat6/common, otherwise it's just the lib folder in your tomcat installation) and all worked just perfectly :)This is probably the best thing that ever happened to web application deployment :D This way you're able to completely reconfigure your application (even the most intimate things like bean properties if you so desire) and all that from as many configuration files as I want (just one works as well).
To utilize the new capabilities I've also reconfigured logging:
log4j = {
appenders {
file name: "application", file: "/var/example/log/example.log"
file name: "stacktrace", file: "/var/example/log/stacktrace.log"
}
debug application: 'grails.app'
(the rest of usual logging settings here...)
}That's soooo cool that I can do that :) It helps me be in line with what the admin of our production environment demands.
And best of all: NO DAMN XML WHATSOEVER :) I love being a Grails developer :)
Tuesday, December 28, 2010
Grails and application.gsp layout - revisited
Hi there folks!
While I'm developing applications in Grails I always like to have good names for things I create. Controllers, domain objects, views... The only thing I couldn't find a good name for until now was application layout.
As you can imagine the names
But (as usual with Grails) there's hope :) You can rename the global catch-all name of the layout to use for everything in the
This way I've specified that the layout named
I hope this will save someone the headache I've had trying to figure this out, especially with the selenium plugin or partial-renderings from actions (like the ones used in Ajah) that when married with the original
While I'm developing applications in Grails I always like to have good names for things I create. Controllers, domain objects, views... The only thing I couldn't find a good name for until now was application layout.
As you can imagine the names
application.gsp or main.gsp seem like a perfect match for application-wide layouts. The problem with main.gsp is that it's already taken by the scaffolding mechanism and it's very unlikely that the whole application will be based on scaffolded views. The problem with application.gsp however is much more severe. Once you create this guy it'll apply to everything even if there's no layout specified. This also applies not only to views but to static resources as well! So before you go ahead and create the application.gsp file be prepared to what's coming on to you.But (as usual with Grails) there's hope :) You can rename the global catch-all name of the layout to use for everything in the
conf/Config.groovy file:grails.sitemesh.default.layout = "none"This way I've specified that the layout named
none.gsp will be used as the catch-all instead of application.gsp and so I can use the latter one for my evil purposes :)I hope this will save someone the headache I've had trying to figure this out, especially with the selenium plugin or partial-renderings from actions (like the ones used in Ajah) that when married with the original
application.gsp looks just wrong all along.
Monday, December 27, 2010
Rails 3.0 - more like Grails :)
Hi there folks!
I can't quite shake the feeling that the new Ruby on Rails in version 3 is more like Grails than it was before :)
Previously everything you did was invoked within the project. There was a
Secondly there is the problem with plugins (or gems as they are called in the Ruby world). Previously you just had to know which gems you needed to run the project which was up to the original project creator to document it. In Grails we've always had the
Man I like seeing ideas being borrowed between opensource projects! This makes the landscape so much more difficult to choose wrong when selecting the proper platform to do the job!
I can't quite shake the feeling that the new Ruby on Rails in version 3 is more like Grails than it was before :)
Previously everything you did was invoked within the project. There was a
script folder that contained scripts to execute. server, generate those are only a few of the examples. In Grails it is different: you get a global command called grails that invokes scripts from either the scripts folder within your project or from a global folder. Well, the new RoR works exactly the same way :) There's a rails command that does exactly the same work :)Secondly there is the problem with plugins (or gems as they are called in the Ruby world). Previously you just had to know which gems you needed to run the project which was up to the original project creator to document it. In Grails we've always had the
appliaction.properties file listing all the required plugins in their respective versions. In RoR 3.0 there's a Gemfile file serving exactly the same purpose :)Man I like seeing ideas being borrowed between opensource projects! This makes the landscape so much more difficult to choose wrong when selecting the proper platform to do the job!
Grails and dynamically generated JavaScript
Hi!
I can already hear you guys explaining in thousands of words why such a thing is inherently bad. I understand that, I even encourage others to do static JavaScript instead of dynamically generated because it is simply better this way. There are however times when having such a thing comes incredibly handy. When?
- whenever you need to pass on some dynamically-generated variables (like URLs for example) and you only want to do it once
- whenever the code depends on some configuration option
There are more examples but the general rule in my opinion is: as long as you keep your JavaScript generation marginal you're on the safe side.
Let's see how we can implement such a thing.
No doubt there's more than one option to do that. The way I've chosen is in my opinion best because it separates the actual program logic from the generation of JavaScript. So what I've done was I've created a separate controller, called ScriptsController, that has some actions on it (usually actions that provide configuration options for the static part of the JavaScript code)
I'm using the outcome of this view as
Because I am a very lazy man and the situation where I need the same set of dynamically-generated content in different views for one controller I've decided to create a tag for it:
So here's the simples usage example:
If however you need to get the script breaking this convention (for whatever reason like common scripts maybe) then the
As usual here's a ready-to-use example.
I hope this will help you out to write less dynamically-generated JavaScript but when you'll have to do it your code will be better structured.
I can already hear you guys explaining in thousands of words why such a thing is inherently bad. I understand that, I even encourage others to do static JavaScript instead of dynamically generated because it is simply better this way. There are however times when having such a thing comes incredibly handy. When?
- whenever you need to pass on some dynamically-generated variables (like URLs for example) and you only want to do it once
- whenever the code depends on some configuration option
There are more examples but the general rule in my opinion is: as long as you keep your JavaScript generation marginal you're on the safe side.
Let's see how we can implement such a thing.
No doubt there's more than one option to do that. The way I've chosen is in my opinion best because it separates the actual program logic from the generation of JavaScript. So what I've done was I've created a separate controller, called ScriptsController, that has some actions on it (usually actions that provide configuration options for the static part of the JavaScript code)
class ScriptsController {
def home = { }
}
I'm using the outcome of this view as
<script
type="text/javascript"
src="${g.createLink(controller: 'script', action: 'home')}.js">
</script><%@ page contentType="text/javascript"%>
var HomeLink = "${g.createLink(controller: 'home', action: 'index')}";Because I am a very lazy man and the situation where I need the same set of dynamically-generated content in different views for one controller I've decided to create a tag for it:
class ExampleTagLib {
static namespace = 'g'
def script = { attrs ->
def link = g.createLink(
controller: 'scripts',
action: attrs.name ?: controllerName)
out << """<script type="text/javascript" src="${link}.js"></script>"""
}
}So here's the simples usage example:
<g:script />script tag that will access the outcome of an action with the same name as the current controller as the src. This is exactly the same as the first version if called from HomeController only shorter.If however you need to get the script breaking this convention (for whatever reason like common scripts maybe) then the
name parameter comes in handy<g:script name="common" />common script will be requested.As usual here's a ready-to-use example.
I hope this will help you out to write less dynamically-generated JavaScript but when you'll have to do it your code will be better structured.
Monday, December 20, 2010
Grails 1.3.6, code-coverage and NTLM authentication error
Hi folks!
It's been a bad, bad day today, let me tell you. I'm still pissed off... but let's start from the beginning.
At first it's been great because the new Grails came out. New means better (and in fact it is better), new features - the usual stuff. Right up until you're forced to work behind an NTLM-protected proxy.
Well, first of all I'd like to point out that giving access to the Internet only via proxy is just asking for trouble. There's tons of apps simply not working from behind a proxy, especially one that needs authentication. Just take all Java applications working on Linux with nothing but the core runtime library and you'll know what I mean.
However up until the previous (1.3.5) version of Grails this problem has been overcomed by using Ivy that registered an NTLM authentication provider and all was just nice and dandy.
But in this version guys have upgraded to version 2.2 of Ivy which turned this feature off until Ivy is really in need to download something from the net. This means that if there's anything counting on proxy being setup correctly you're going to find yourself in deep sh..t.
There are 2 methods to overcome this problem:
1. Downgrade to Grails 1.3.5 (I'd recommend that unless like me you really need some of the new features that came to be in 1.3.6 like the "run-script" thingy - extra handy!!!)
2. Install a proxy server that can communicate with an up-stream NTLM-protected proxy
If you're counting on some bad-ass sites telling you to set the http.proxyUser and http.proxyPassword system settings to get it to work again please be adviced that it's just plain not true. This had been so ages ago, but now things are a lot more complicated and this mechanism ain't working anymore. Period.
Just remember: if you'll see something like this:
you're having issues with authorization (it's the 407 part of this call stack)
I hope this will help save someone tons of time that I spent to figure this damn thing out.
Oh! And if it'd not be enough it works just fine on Windows when you're logged in to the domain. Go figure!
Edit on April 25th, 2011
Mike was kind enough to apply a hotfix that I made to the code-coverage plugin. This hotfix disables loading of external DTDs while processing cobertura.xml file. To that end if you're using this one and facing the issue described below you'll want to upgrade the plugin to version 1.2.3.It's been a bad, bad day today, let me tell you. I'm still pissed off... but let's start from the beginning.
At first it's been great because the new Grails came out. New means better (and in fact it is better), new features - the usual stuff. Right up until you're forced to work behind an NTLM-protected proxy.
Well, first of all I'd like to point out that giving access to the Internet only via proxy is just asking for trouble. There's tons of apps simply not working from behind a proxy, especially one that needs authentication. Just take all Java applications working on Linux with nothing but the core runtime library and you'll know what I mean.
However up until the previous (1.3.5) version of Grails this problem has been overcomed by using Ivy that registered an NTLM authentication provider and all was just nice and dandy.
But in this version guys have upgraded to version 2.2 of Ivy which turned this feature off until Ivy is really in need to download something from the net. This means that if there's anything counting on proxy being setup correctly you're going to find yourself in deep sh..t.
There are 2 methods to overcome this problem:
1. Downgrade to Grails 1.3.5 (I'd recommend that unless like me you really need some of the new features that came to be in 1.3.6 like the "run-script" thingy - extra handy!!!)
2. Install a proxy server that can communicate with an up-stream NTLM-protected proxy
If you're counting on some bad-ass sites telling you to set the http.proxyUser and http.proxyPassword system settings to get it to work again please be adviced that it's just plain not true. This had been so ages ago, but now things are a lot more complicated and this mechanism ain't working anymore. Period.
Just remember: if you'll see something like this:
java.io.IOException: Server returned HTTP response code: 407 for URL: http://cobertura.sourceforge.net/xml/coverage-04.dtd
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:677)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1315)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1282)
at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:283)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1194)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1090)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1003)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at _Events.replaceClosureNamesInXmlReports(_Events.groovy:118)
at _Events$replaceClosureNamesInXmlReports.callCurrent(Unknown Source)
at _Events.replaceClosureNamesInReports(_Events.groovy:89)
at _Events$_run_closure2.doCall(_Events.groovy:42)
at _GrailsEvents_groovy$_run_closure5.doCall(_GrailsEvents_groovy:58)
at _GrailsEvents_groovy$_run_closure5.call(_GrailsEvents_groovy)
at _GrailsTest_groovy$_run_closure1.doCall(_GrailsTest_groovy:203)
at TestApp$_run_closure1.doCall(TestApp.groovy:82)
at gant.Gant$_dispatch_closure5.doCall(Gant.groovy:381)
at gant.Gant$_dispatch_closure7.doCall(Gant.groovy:415)
at gant.Gant$_dispatch_closure7.doCall(Gant.groovy)
at gant.Gant.withBuildListeners(Gant.groovy:427)
at gant.Gant.this$2$withBuildListeners(Gant.groovy)
at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
at gant.Gant.dispatch(Gant.groovy:415)
at gant.Gant.this$2$dispatch(Gant.groovy)
at gant.Gant.invokeMethod(Gant.groovy)
at gant.Gant.executeTargets(Gant.groovy:590)
at gant.Gant.executeTargets(Gant.groovy:589)you're having issues with authorization (it's the 407 part of this call stack)
I hope this will help save someone tons of time that I spent to figure this damn thing out.
Oh! And if it'd not be enough it works just fine on Windows when you're logged in to the domain. Go figure!
Saturday, December 18, 2010
Grails T'n'T: Accessing current controller from a command object
Hi there folks!
This time we're going to talk about how to access the current controller instance from anywhere in the code. We're going to demonstrate this by the Command object example.
Imagine you're in a command object's method and want to call the
Let's add the following method to our command object:
This way we get a read-only property called
But there's more!
Imagine you'd like to access the current request, response or session from the command object. All you need to do is to get there via the controller:
Even the
I sure hope this will help you out in refactoring your code from the controller into external classes like the command objects.
Have fun!
This time we're going to talk about how to access the current controller instance from anywhere in the code. We're going to demonstrate this by the Command object example.
Imagine you're in a command object's method and want to call the
render method. All would be nice and dandy if it'd be the controller itself but it turns out the command object is more like a domain class (with its ability to verify field values and so on) than anything else. But... there's hope!Let's add the following method to our command object:
private getController() {
RequestContextHolder.
requestAttributes.
request.
getAttribute(GrailsApplicationAttributes.CONTROLLER)
}
This way we get a read-only property called
controller that we can use to call the render method. But there's more!
Imagine you'd like to access the current request, response or session from the command object. All you need to do is to get there via the controller:
controller.session
controller.request
controller.responseEven the
params element of the controller is available!I sure hope this will help you out in refactoring your code from the controller into external classes like the command objects.
Have fun!
Grails and external configuration - the easy way
Hi folks!
This time we're going to work towards the ability to change application's configuration after deployment. In spring what you usually do is allow for loading some settings from a configuration file first prior to setting the defaults. This way once a particular key has been set in the override it's not going to be overridden by the defaults in your applicationContext.xml or beans.xml (however you wanna call it).
In Grails thanks to the existence of another mechanism we can do it differently. We can instruct Grails to load overrides if they have been declared in either the system properties for currently running process (using the -D notation in JAVA_OPTS) or plain in environment options.
The first option is dead simple. What you need to do is to go to your conf/Config.groovy and uncomment the following lines near the top of the file (at least in the original one):
Unfortunately when you do that and set the proper setting during the invocation of java process that started your application (that'd be Tomcat) you'll be presented with an error message like this:
This is due to the fact that the
Once that's done you're able to specify the additional config location in JAVA_OPTS and live is good :)
The other option is to change the predefined code to look for an environment variable instead:
This way instead of looking for parameters specified via the -D option while invoking the Java virtual machine it'll look for an environment variable.
Surely you'll find more ways to specify the config file location. The beauty of this solution lies in diversity :)
I hope it'll help someone!
This time we're going to work towards the ability to change application's configuration after deployment. In spring what you usually do is allow for loading some settings from a configuration file first prior to setting the defaults. This way once a particular key has been set in the override it's not going to be overridden by the defaults in your applicationContext.xml or beans.xml (however you wanna call it).
In Grails thanks to the existence of another mechanism we can do it differently. We can instruct Grails to load overrides if they have been declared in either the system properties for currently running process (using the -D notation in JAVA_OPTS) or plain in environment options.
The first option is dead simple. What you need to do is to go to your conf/Config.groovy and uncomment the following lines near the top of the file (at least in the original one):
if(System.properties["${appName}.config.location"]) {
grails.config.locations << "file:" + System.properties["${appName}.config.location"]
}
Unfortunately when you do that and set the proper setting during the invocation of java process that started your application (that'd be Tomcat) you'll be presented with an error message like this:
log4j:ERROR Error initializing log4j: No signature of method:
groovy.util.ConfigObject.leftShift() is applicable for argument
types: (java.lang.String) values: [file:]
Possible solutions: leftShift(java.util.Map$Entry), leftShift(java.util.Map)
groovy.lang.MissingMethodException: No signature of method:
groovy.util.ConfigObject.leftShift() is applicable for argument types:
(java.lang.String) values: [file:]
Possible solutions: leftShift(java.util.Map$Entry), leftShift(java.util.Map)
at Config.run(Config.groovy:17)
2010-12-18 22:30:46 org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
2010-12-18 22:30:46 org.apache.catalina.core.StandardContext start
SEVERE: Context [/] startup failed due to previous errors
This is due to the fact that the
grails.config.locations element is not set by default. To fix this simply add the following line just before the the code you've just uncommented:
grails.config.locations = []
Once that's done you're able to specify the additional config location in JAVA_OPTS and live is good :)
The other option is to change the predefined code to look for an environment variable instead:
if(System.getenv()["${appName}.config.location"]) {
grails.config.locations << "file:" + System.getenv()["${appName}.config.location"]
}
This way instead of looking for parameters specified via the -D option while invoking the Java virtual machine it'll look for an environment variable.
Surely you'll find more ways to specify the config file location. The beauty of this solution lies in diversity :)
I hope it'll help someone!
Grails 1.3.6 is here!
Hi folks!
Grails 1.3.6 is here and kicks ass again with one of the coolest features ever! The "run-script" command :)
I admit it has been possible for some time now as mentioned on some blogs but actually having it as part of the framework is a kick-ass productivity boost for anyone that needs to perform administrative tasks on regular basis!
Besides the feature mentioned above it is imperative that you check out the externalized configuration options possibility. This time I'll just simply say "finally"! This stuff has been missing from the framework for a long time! I know it was possible to implement override from an external configuration file but the way it looks now is just as it should be from the beginning!
Fantastic job Grails team! Thank you very very much!
Grails 1.3.6 is here and kicks ass again with one of the coolest features ever! The "run-script" command :)
I admit it has been possible for some time now as mentioned on some blogs but actually having it as part of the framework is a kick-ass productivity boost for anyone that needs to perform administrative tasks on regular basis!
Besides the feature mentioned above it is imperative that you check out the externalized configuration options possibility. This time I'll just simply say "finally"! This stuff has been missing from the framework for a long time! I know it was possible to implement override from an external configuration file but the way it looks now is just as it should be from the beginning!
Fantastic job Grails team! Thank you very very much!
Tuesday, December 14, 2010
Grails Routing plugin released!
Hi all,
Today I've released the first version of grails-routing plugin. It's a modernized version of the original grails-camel plugin by Chris Navta with some extras included.
First of all, if you plan to target Apache Camel 1.6.x this plugin is no good for you as it works only with 2.4.0. It's been ages since 1.6 was released and the original author did not express interest in providing an update.
Secondly there are 2 exciting features included:
- integration with grails-quartz plugin to allow jobs to send messages
- integration with Ivy to download all the necessary dependencies
As I am not leaving my audience without ready-to-use examples (by definition) you'll also find 3 of those:
- basic usage example
- Quartz plugin integration example
- ActiveMQ usage example
I hope it'll serve you well!
Today I've released the first version of grails-routing plugin. It's a modernized version of the original grails-camel plugin by Chris Navta with some extras included.
First of all, if you plan to target Apache Camel 1.6.x this plugin is no good for you as it works only with 2.4.0. It's been ages since 1.6 was released and the original author did not express interest in providing an update.
Secondly there are 2 exciting features included:
- integration with grails-quartz plugin to allow jobs to send messages
- integration with Ivy to download all the necessary dependencies
As I am not leaving my audience without ready-to-use examples (by definition) you'll also find 3 of those:
- basic usage example
- Quartz plugin integration example
- ActiveMQ usage example
I hope it'll serve you well!
Sunday, December 5, 2010
Grails vs JSF - 6 months summary
Hi there folks!
I's been exactly 6 months since I left my previous team where I've had to endure JSF programming for more than a year. Starting July 6 this year I moved to another team where I was finally able to choose the technology I want to work with.
Here are some facts you might find interesting when choosing the web framework:
1. JSF.
- previous project status: in progress...
- team size: 4 developers, 1 architect (doing nothing but breaking the code and managing people since he is the official manager for the team), 2 QAs (doing nothing because of how JSF works)
- project size: too big; needs refactoring into smaller pieces.
- project complexity: waaaaay to high; needs refactoring into smaller pieces.
- code coverage: less than 20%; needs improvement.
- current project status: STILL NOT COMPLETED, 6 developers, 1 and the same architect, don't know about the QAs, but one of them loudly complains he doesn't want to have anything to do with this app :D
- overall experience: I hate my job and I want to die
2. Grails
- team size: 1 developer in the role of architect, QA and programmer and 1 database master, separate manager that does what she(!) is supposed to do which is to help people and not to kill their productivity!
- project size: a lot smaller
- project complexity:
UI: 4/10
server side: 2/10
- project releases from ground zero: 3 (this was a green field project)
- code coverage: constantly between 88% and 98%
- overall experience: I love my job again!
So if you think you're one of the great software architects and you don't need to code because there are others to do that: QUIT YOUR JOB AND STOP DOING ANY MORE DAMAGE!!!
And if you still consider JSF to be a viable option: change your profession! You're probably better of in politics :)
Man, I needed to get that out of my chest :D I'm feeling lucky!
I's been exactly 6 months since I left my previous team where I've had to endure JSF programming for more than a year. Starting July 6 this year I moved to another team where I was finally able to choose the technology I want to work with.
Here are some facts you might find interesting when choosing the web framework:
1. JSF.
- previous project status: in progress...
- team size: 4 developers, 1 architect (doing nothing but breaking the code and managing people since he is the official manager for the team), 2 QAs (doing nothing because of how JSF works)
- project size: too big; needs refactoring into smaller pieces.
- project complexity: waaaaay to high; needs refactoring into smaller pieces.
- code coverage: less than 20%; needs improvement.
- current project status: STILL NOT COMPLETED, 6 developers, 1 and the same architect, don't know about the QAs, but one of them loudly complains he doesn't want to have anything to do with this app :D
- overall experience: I hate my job and I want to die
2. Grails
- team size: 1 developer in the role of architect, QA and programmer and 1 database master, separate manager that does what she(!) is supposed to do which is to help people and not to kill their productivity!
- project size: a lot smaller
- project complexity:
UI: 4/10
server side: 2/10
- project releases from ground zero: 3 (this was a green field project)
- code coverage: constantly between 88% and 98%
- overall experience: I love my job again!
So if you think you're one of the great software architects and you don't need to code because there are others to do that: QUIT YOUR JOB AND STOP DOING ANY MORE DAMAGE!!!
And if you still consider JSF to be a viable option: change your profession! You're probably better of in politics :)
Man, I needed to get that out of my chest :D I'm feeling lucky!
Subscribe to:
Comments (Atom)