tag:old.nabble.com,2006:forum-11866Nabble - codehaus - Groovy2009-11-10T12:10:23Z<img src="http://media.xircles.codehaus.org/_projects/groovy/_logos/medium.png" border="0" />
Groovy is a new agile dynamic language for the JVM. codehaus - Groovy home is <a href="http://groovy.codehaus.org/" target="_top" rel="nofollow">here</a>tag:old.nabble.com,2006:post-26289081Re: On static compilation of Groovy2009-11-10T12:10:23Z2009-11-10T12:10:23ZsimonzAlex,
<p>
Thanks for writing such a thoughtful article, I really enjoyed reading it.
<p>
I too would love to see Groovy get some optional static compilation features. I say this because I really do love programming in Groovy but in my heart of hearts, I know I will probably recommend Scala instead of Groovy to many people in the end because of the issues you mention. It makes me sad because I feel like this is an unnecessary and unfortunate outcome. Groovy only needs some very minor static typing features in my view to completely solve the problem, and such an outcome would make it easily better than Scala for most people's needs.
<pre>@Static
class Foo {
int x;
String fubar(Bar bar) {
return 5; // compile error
}
};</pre>
<pre>
static int 5;
String cat = 5; // compile error
</pre>
I don't accept the argument that because IDEs highlight some warnings that it makes up for static typing being missing. Often type errors come when you combine separate modules, upgrade versions etc. You are not necessarily staring at the IDE, looking at the code in question when the problem occurs. You are compiling with groovyc. And even if you are staring at your IDE, do you really want to see thousands of harmless warnings all over your code for those places where the IDE can't decide if you broke the code or not?
<p>
Sadly I'm not smart enough to contribute to all this intelligently at the language level. But I know that I want it and if I had it I would definitely be increasing the scope of where and how I deploy groovy.
<p>
Cheers,
<p>
Simon.<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26288894Re: On static compilation of Groovy2009-11-10T10:34:01Z2009-11-10T10:34:01ZRobert Fischer > This reminds me of the discussion about having a joint compiler for Java and Groovy.
<br> >
<br> > All the Groovy bigger heads were totally against it [...]
<br> >
<br><br>I just don't want it to be officially supported by Groovy. I think it's going to open up a world of
<br>hurt and annoyance for the maintainer (I'm envisioning weekly refrains of "Can I de-statically
<br>compile a statically compiled class?"), and I'd rather that the core Groovy people be left outside
<br>of that loop so they can stay productive on more useful and less error-causing things.
<br><br>~~ Robert Fischer, Smokejumper IT Consulting.
<br>Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br><br>Grails Expert Retainer Services
<br><a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br><br><br>Michael Baehr wrote:
<div class='shrinkable-quote'><br>> This reminds me of the discussion about having a joint compiler for Java and Groovy.
<br>>
<br>> All the Groovy bigger heads were totally against it (do a search and you will find a similar list of threads), 'til somebody by the name Alex Tkachman just created one - and since then the project leads declared it as the best thing since sliced bread.
<br>>
<br>> So Alex, just go for it - there are obviously enough people who would want to have something like that.
<br>>
<br>> cu
<br>>
<br>> Michael
<br>>
<br>> On 10. Nov 2009, at 6:19, Robert Fischer wrote:
<br>>
<br>>>> All this idea of a "static groovy" mode has been debated so many times
<br>>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>>> points about it.
<br>>>> Just a one minute search brought me numerous threads on the topics, on
<br>>>> the challenges and issues about this static groovy idea:
<br>>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>> Best. Rebuttal. EVAR.
<br>>>
<br>>>
<br>>> ~~ Robert Fischer, Smokejumper IT Consulting.
<br>>> Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br>>>
<br>>> Grails Expert Retainer Services
<br>>> <a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br>>>
<br>>>
<br>>> Guillaume Laforge wrote:
<br>>>> On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26288894&i=0" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>>>>> In your article you make the assertion, "due to performance reasons Groovy is
<br>>>>> almost useless today for multi-core programming" without giving any reasons or
<br>>>>> data to defend the assertion. I can't think of why this assertion should
<br>>>>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>>>>> this holds for any number of threads and any number of cores. Why would
<br>>>>> properly parallelized Groovy code be inappropriate for code that engages in
<br>>>>> lots of IO, which is the bulk of what business oriented code does?
<br>>>> Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>>>> usually ridiculous compared to the time software waits for data to
<br>>>> come up from the database. And optimizing the IO access is usually
<br>>>> going to offer leaps in the scalability and/or performance of your
<br>>>> code.
<br>>>>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>>>>> entirely transparent for end users, 2) It does not increase the complexity of
<br>>>>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>>>>> other features, and 3) It changes none of the semantics of current Groovy
<br>>>>> code. I doubt those three things are possible, but I am willing to be proved
<br>>>>> wrong.
<br>>>> All this idea of a "static groovy" mode has been debated so many times
<br>>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>>> points about it.
<br>>>> Just a one minute search brought me numerous threads on the topics, on
<br>>>> the challenges and issues about this static groovy idea:
<br>>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>>> And I'm sure there are even older threads on the topic.
<br>>>> But to answer your points: 1) It won't be transparent in the sense
<br>>>> that you would have to demarcate the code that would be made "static"
<br>>>> (not a bad thing per se, though), but then avoid mixing static /
<br>>>> non-static code, otherwise you wouldn't be able to really know what is
<br>>>> or what is not statically compiled. 2) Of course it'll increase the
<br>>>> complexity of the compiler. More advanced / complex features means
<br>>>> more complexity to deal with, more bugs, a longer time to get it
<br>>>> right, less resource / time to work on other features. And 3) it'd
<br>>>> definitely change the semantics of current Groovy code, as for
<br>>>> instance, the method resolution in a static mode is different from a
<br>>>> dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>>>> calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>>>> static vs non-static mode. Groovy choses the method according to the
<br>>>> runtime type, a static mode wouldn't.
<br>>>> So this is all far from seamless, transparent. In the end, it somehow
<br>>>> means maintaining two compilers in one.
<br>>>>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>>>>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>>>>> sometime in the future?
<br>>>> It's still early to really tell, as "invokedynamic" is still a work in
<br>>>> progress. But hopefully, some significant gains will come from it,
<br>>>> although it's still difficult to know what the real gains will be till
<br>>>> there's a definitive working version available and testable.
<br>>>> But I'd much rather see efforts improving "dynamic Groovy"
<br>>>> (performance, features, etc), than abandonning this idea and turning
<br>>>> Groovy into Java plus some syntaxic sugar only.
<br>>>>> Also, if the objections to static compiling that I raised above cannot be met
<br>>>>> there are alternatives to speeding up Groovy code that seem easier to
<br>>>>> implement but would give big speedups to performance critical code. One would
<br>>>>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>>>>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>>>>> and Scala, so this doesn't provide anything that can't already be done, it
<br>>>>> simply provides convenience to the programmer.
<br>>>> The integration is pretty much seamless already.
<br>>>> Adding a small Java class for a routine that needs to be speed up is so easy.
<br>>>> Once you've got your project build using the groovyc compiler (Ant
<br>>>> build, GMaven, Gradle, whatever), you usually don't have much work to
<br>>>> do to joint-compile Groovy and Java together -- perhaps just a few
<br>>>> lines to customize the javac call.
<br>>>> The benefit also is it clearly demarcates what's statically-compiled
<br>>>> (Java) and what's your dynamic code (Groovy).
<br>>>>> [...]
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
</div><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26287336Re: Handling RESTClient post() responses with no content-type or body.2009-11-10T09:20:42Z2009-11-10T09:20:42ZJon BrittonHi,
<br><br>I used Maven to update my dependencies and I'm pretty certain that I'm using the right JAR. I don't have access to a public GeoServer instance unfortunately, although it's pretty easy to install GeoServer on a local machine (you also need the GeoServer REST plugin which you need to put in webapps/geoserver/web-inf/lib/) especially if you happen to have Tomcat running (you can get a WAR).
<br><br>One strange thing is that Eclipse seems to show http-builder-0.5.0-SNAPSHOT.jar, even though Maven downloaded the timestamped version. I'm not sure if it actually replaced it, but it doesn't matter because I get the same result regardless of the JAR I use.
<br><br>Here is the stack trace again so you can see the line numbers etc:
<br><br>10-Nov-2009 17:18:42 groovyx.net.http.ParserRegistry getContentType
<br>WARNING: Could not parse content-type header in response
<br>java.lang.NullPointerException
<br> at groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:151)
<br> at groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:511)
<br> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:462)
<br> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br> at java.lang.reflect.Method.invoke(Unknown Source)
<br> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSi
<br>te.java:229)
<br> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br> at uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:46)
<br> at uk.ac.glam.rest.GroovyTest$createWorkspace.callCurrent(Unknown Source)
<br> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:69)
<br> at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br> at java.lang.reflect.Method.invoke(Unknown Source)
<br> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>10-Nov-2009 17:18:42 groovyx.net.http.HTTPBuilder doRequest
<br>WARNING: Error parsing 'null' response
<br>java.lang.IllegalArgumentException: Could not parse content-type from response
<br> at groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:155)
<br> at groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:511)
<br> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:462)
<br> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br> at java.lang.reflect.Method.invoke(Unknown Source)
<br> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSi
<br>te.java:229)
<br> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br> at uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:46)
<br> at uk.ac.glam.rest.GroovyTest$createWorkspace.callCurrent(Unknown Source)
<br> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:69)
<br> at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br> at java.lang.reflect.Method.invoke(Unknown Source)
<br> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>Caught: groovyx.net.http.ResponseParseException: Internal Server Error
<br> at uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:46)
<br> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:69)
<br><br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Tom Nichols wrote:</div>
<div class="quote-message shrinkable-quote">Hi Jon,
<br><br>Are you sure you got an updated snapshot? It was published on Nov
<br>6th. You can get the timestamped version of the JAR here:
<br><a href="http://snapshots.repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0-SNAPSHOT/http-builder-0.5.0-20091107.042829-12.jar" target="_top" rel="nofollow">http://snapshots.repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0-SNAPSHOT/http-builder-0.5.0-20091107.042829-12.jar</a><br><br>I'm surprised that you'd see _no_ change in the behavior. Although
<br>part of the problem is I'm trying to fix this "blind," so to speak,
<br>without being able to reproduce it myself. Can you point me to a
<br>public GeoServer instance, or your dev server which I can use to test
<br>things while I develop the fix? I'm certain this is not just
<br>GeoServer's fault. While uncommon, it's not a requirement for a
<br>response to contain a body. Therefore RESTClient should be able to
<br>handle the case and I'm more than willing to work with you to get it
<br>fixed in the HTTPBuilder code.
<br><br>Can you please also verify that the exception stack trace is
<br>identical, once you've verified that you're using an updated snapshot?
<br> Thanks.
<br><br>-Tom
<br><br>On Tue, Nov 10, 2009 at 9:29 AM, Jon Britton
<br><man_kills_everything@hotmail.com> wrote:
<br>>
<br>> Hi Tom,
<br>>
<br>> I've just tried again with 0.5.0-SNAPSHOT and my original code (the
<br>> RESTClient one) and I'm still getting the same exceptions
<br>> (NullPointerException, IllegalArgumentException and ResponseParseException).
<br>>
<br>> Again, here is the code I'm using:
<br>>
<br>> def createWorkspace(workspace, geoserverUrl, user, pass){
<br>> // setup the restclient
<br>> def geoserver = new RESTClient(geoserverUrl)
<br>> // do the authing
<br>> geoserver.auth.basic user, pass
<br>> // post it
<br>> def res = geoserver.post( path: "/geoserver/rest/workspaces",
<br>> requestContentType: XML,
<br>> body: "<workspace><name>${workspace}</name></workspace>"
<br>> ).getStatus()
<br>> }
<br>>
<br>> I guess this is all GeoServers fault?
<br>>
<br>> Jon
<br>>
<br>>
<br>> Tom Nichols wrote:
<br>>>
<br>>> Hi Jon,
<br>>>
<br>>> I just deployed a new 0.5.0-SNAPSHOT release; this should fix the
<br>>> empty response body issue. For RESTClient responses, response.data
<br>>> should simply be null. But all header/ response code information
<br>>> should be readily available. Please give it a try and let me know
<br>>> what you find.
<br>>>
<br>>> Thanks.
<br>>> -Tom
<br>>>
<br>>>
<br>>>
<br>>> On Fri, Nov 6, 2009 at 11:11 AM, Tom Nichols <tmnichols@gmail.com> wrote:
<br>>>> hmm, I'm not sure what to tell you; I just copied your example into a
<br>>>> Groovy console and ran it, and I didn't get the MissingMethodException
<br>>>> that you're seeing there, using 0.5.0-RC2.
<br>>>>
<br>>>> Try this variation:
<br>>>> def http = new groovyx.net.http.HTTPBuilder(
<br>>>> "<a href="http://localhost:8080/geoserver/rest/workspaces" target="_top" rel="nofollow">http://localhost:8080/geoserver/rest/workspaces</a>" )
<br>>>> http.handler.SUCCESS = { return it }
<br>>>>
<br>>>> def response = http.post( headers:['Content-Type': 'text/xml'],
<br>>>> body: "<workspace><name>bob</name></workspace>" )
<br>>>>
<br>>>> assert response.status == 201
<br>>>>
<br>>>>
<br>>>>
<br>>>> 2009/11/6 Jon Britton <man_kills_everything@hotmail.com>:
<br>>>>>
<br>>>>> Hi again, I'm just trying your example without using RESTClient but it
<br>>>>> doesn't work. My code is below, followed by the error I receive. What's
<br>>>>> could be causing this?
<br>>>>>
<br>>>>> Thanks,
<br>>>>>
<br>>>>> Jon
<br>>>>>
<br>>>>> CODE:
<br>>>>>
<br>>>>> def createWorkspace(def wsName, def geoserverUrl, def user, def pass){
<br>>>>> def http = new HTTPBuilder(
<br>>>>> "${geoserverUrl}/geoserver/rest/workspaces" )
<br>>>>> http.handler.SUCCESS = { return it }
<br>>>>>
<br>>>>> def response = http.request( POST, XML ) {
<br>>>>> body = "<workspace><name>${wsName}</name></workspace>"
<br>>>>> }
<br>>>>>
<br>>>>> assert response.status == 201
<br>>>>> }
<br>>>>>
<br>>>>> //Call method
<br>>>>> def code = createWorkspace("hello1",
<br>>>>> "<a href="http://admin:geoserver@localhost:8080/" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/</a>", "admin", "geoserver")
<br>>>>>
<br>>>>> OUTPUT:
<br>>>>>
<br>>>>> Caught: groovy.lang.MissingMethodException: No signature of method:
<br>>>>> groovyx.net.http.HTTPBuilder.request() is applicable
<br>>>>> for argument types: (groovyx.net.http.Method,
<br>>>>> groovyx.net.http.ContentType,
<br>>>>> uk.ac.glam.rest.GroovyTest$_createWorkspace
<br>>>>> _closure2) values: [POST, application/xml,
<br>>>>> uk.ac.glam.rest.GroovyTest$_createWorkspace_closure2@2fb002]
<br>>>>> at
<br>>>>> uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:54)
<br>>>>> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:70)
<br>>>>>
<br>>>>>
<br>>>>>
<br>>>>> Tom Nichols wrote:
<br>>>>>>
<br>>>>>> Nope, you're right; in that case, the response object should be
<br>>>>>> available, and the 'data' property (which is the parsed response body)
<br>>>>>> should just be null. Definitely a bug.
<br>>>>>>
<br>>>>>> However, after looking at the stack trace, I don't think you should be
<br>>>>>> getting an NPE but an IllegalArgumentException (this is still
<br>>>>>> erroneous in the case of RESTClient, but it's due to RESTClient's
<br>>>>>> underlying use of HTTPBuilder). What version of HTTPBuilder are you
<br>>>>>> using?
<br>>>>>>
<br>>>>>> In either case, the bug still stands; I'll start working on it
<br>>>>>> soon-ish. You can work around it for now by using the HTTPBuilder
<br>>>>>> class directly, which other than being slightly more verbose can do
<br>>>>>> the exact thing you're doing with RESTClient.
<br>>>>>>
<br>>>>>> import static groovyx.net.http.Method.POST
<br>>>>>> import static groovyx.net.http.ContentType.XML
<br>>>>>>
<br>>>>>> def http = new HTTPBuilder(
<br>>>>>> '<a href="http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'</a> )
<br>>>>>> http.handler.SUCCESS = { return it }
<br>>>>>>
<br>>>>>> def response = http.request( POST, XML ) {
<br>>>>>> body = '<workspace><name>dwins</name></workspace>'
<br>>>>>> }
<br>>>>>>
<br>>>>>> assert response.status == 201
<br>>>>>>
<br>>>>>>
<br>>>>>> Let me know if you have any trouble with the above example.
<br>>>>>> -Tom
<br>>>>>>
<br>>>>>>
<br>>>>>> On Thu, Nov 5, 2009 at 9:45 AM, Jon Britton
<br>>>>>> <man_kills_everything@hotmail.com> wrote:
<br>>>>>>>
<br>>>>>>> Sorry, forgot the full stack trace:
<br>>>>>>>
<br>>>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.ParserRegistry getContentType
<br>>>>>>> WARNING: Could not parse content-type header in response
<br>>>>>>> java.lang.NullPointerException
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:153)
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>>>> Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>> at
<br>>>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.HTTPBuilder doRequest
<br>>>>>>> WARNING: Error parsing 'null' response
<br>>>>>>> java.lang.IllegalArgumentException: Could not parse content-type from
<br>>>>>>> response
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:157)
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>>>> Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>> at
<br>>>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>>>> Caught: groovyx.net.http.ResponseParseException: Created
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>>
<br>>>>>>>
<br>>>>>>>
<br>>>>>>> Tom Nichols wrote:
<br>>>>>>>>
<br>>>>>>>> Hmm interesting. I was under the assumption that a POST response
<br>>>>>>>> should include _some_ sort of response body, but maybe that's not
<br>>>>>>>> technically required by the HTTP spec. If you can send me the
<br>>>>>>>> exception stack trace I'm sure I can fix it, but I can't tell you
<br>>>>>>>> what
<br>>>>>>>> you yourself can do until you give me some more details.
<br>>>>>>>>
<br>>>>>>>> Better yet, if you can file a JIRA here:
<br>>>>>>>> <a href="http://jira.codehaus.org/browse/GMOD" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GMOD</a><br>>>>>>>> that would be super awesome (put the bug under the "HTTPBuilder"
<br>>>>>>>> module). And If you really want to earn karma points, give enough of
<br>>>>>>>> an example that I can reproduce the error condition myself :) I
<br>>>>>>>> don't
<br>>>>>>>> konw if GeoServer has an open API, but if they do I can add it to the
<br>>>>>>>> unit tests.
<br>>>>>>>>
<br>>>>>>>> Thanks.
<br>>>>>>>> -Tom
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>> On Thu, Nov 5, 2009 at 9:22 AM, Jon Britton
<br>>>>>>>> <man_kills_everything@hotmail.com> wrote:
<br>>>>>>>>>
<br>>>>>>>>> Hi,
<br>>>>>>>>> I'm using RESTClient from the HTTP Builder module to send a POST
<br>>>>>>>>> request
<br>>>>>>>>> to
<br>>>>>>>>> GeoServer. However, the response to my request doesn't contain a
<br>>>>>>>>> content-type or body so I get the following followed by a number of
<br>>>>>>>>> exceptions:
<br>>>>>>>>>
<br>>>>>>>>> 05-Nov-2009 14:12:42 groovyx.net.http.ParserRegistry getContentType
<br>>>>>>>>> WARNING: Could not parse content-type header in response
<br>>>>>>>>>
<br>>>>>>>>> Followed by exceptions. How can I get around this? All I want from
<br>>>>>>>>> the
<br>>>>>>>>> response is the status code, I'm not interested in anything else.
<br>>>>>>>>> My
<br>>>>>>>>> code
<br>>>>>>>>> is shown below.
<br>>>>>>>>>
<br>>>>>>>>> Thanks,
<br>>>>>>>>>
<br>>>>>>>>> Jon
<br>>>>>>>>>
<br>>>>>>>>> Code:
<br>>>>>>>>>
<br>>>>>>>>> def createWorkspace(def wsName, def geoserverUrl, def user, def
<br>>>>>>>>> pass){
<br>>>>>>>>> // setup the restclient
<br>>>>>>>>> def geoserver = new RESTClient(geoserverUrl)
<br>>>>>>>>> // do the authing
<br>>>>>>>>> geoserver.auth.basic user, pass
<br>>>>>>>>> // post it
<br>>>>>>>>> def res = geoserver.post( path: "geoserver/rest/workspaces",
<br>>>>>>>>> requestContentType: XML,
<br>>>>>>>>> body: "<workspace><name>${wsName}</name></workspace>"
<br>>>>>>>>> )
<br>>>>>>>>> }
<br>>>>>>>>>
<br>>>>>>>>> def code = createWorkspace("hello", "<a href="http://localhost:8080/" target="_top" rel="nofollow">http://localhost:8080/</a>",
<br>>>>>>>>> "admin",
<br>>>>>>>>> "geoserver")
<br>>>>>>>>> --
<br>>>>>>>>> View this message in context:
<br>>>>>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html</a><br>>>>>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>> ---------------------------------------------------------------------
<br>>>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>>>
<br>>>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>
<br>>>>>>>> ---------------------------------------------------------------------
<br>>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>>
<br>>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>
<br>>>>>>> --
<br>>>>>>> View this message in context:
<br>>>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html</a><br>>>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>>>
<br>>>>>>>
<br>>>>>>> ---------------------------------------------------------------------
<br>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>
<br>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>
<br>>>>>>>
<br>>>>>>>
<br>>>>>>
<br>>>>>> ---------------------------------------------------------------------
<br>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>
<br>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>
<br>>>>> --
<br>>>>> View this message in context:
<br>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html</a><br>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>
<br>>>>>
<br>>>>> ---------------------------------------------------------------------
<br>>>>> To unsubscribe from this list, please visit:
<br>>>>>
<br>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>
<br>>>>>
<br>>>>>
<br>>>>
<br>>>
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>>
<br>>>
<br>>
<br>> --
<br>> View this message in context: <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26284361.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26284361.html</a><br>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
<br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br></div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26286275Re: as Integer doesn't work with GStringImpl?2009-11-10T08:14:31Z2009-11-10T08:14:31ZJochen TheodorouTim Yates schrieb:
<div class='shrinkable-quote'><br>> Hiya, is this JIRA worthy?
<br>>
<br>> "-1" as Integer
<br>>
<br>>
<br>> returns -1
<br>>
<br>> however:
<br>>
<br>> a = '-1'
<br>> "$a" as Integer
<br>>
<br>>
<br>> gives
<br>>
<br>>
<br>> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '-1' with class 'org.codehaus.groovy.runtime.GStringImpl' to class 'java.lang.Integer'
</div><br>yes, please fill a JIRA for this
<br><br>bye blackdrag
<br><br>--
<br>Jochen "blackdrag" Theodorou
<br>The Groovy Project Tech Lead (<a href="http://groovy.codehaus.org" target="_top" rel="nofollow">http://groovy.codehaus.org</a>)
<br><a href="http://blackdragsview.blogspot.com/" target="_top" rel="nofollow">http://blackdragsview.blogspot.com/</a><br><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26285832Re: Converting COBOL trailing sign numeric to BigDecimal2009-11-10T07:51:51Z2009-11-10T07:51:51ZTim YatesSorry...I'd assumed you'd tried the DecimalFormat method and it hadn't worked...<br><br>Why not use this:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<span style="font-family: courier new,monospace;" class="js-keyword">def </span><span style="font-family: courier new,monospace;" class="js-variable">number </span><span style="font-family: courier new,monospace;" class="js-operator">= </span><span style="font-family: courier new,monospace;" class="js-string">"12345678-"</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;" class="js-keyword">new </span><span style="font-family: courier new,monospace;" class="js-variable">java</span><span style="font-family: courier new,monospace;" class="js-punctuation">.</span><span style="font-family: courier new,monospace;" class="js-variable">text</span><span style="font-family: courier new,monospace;" class="js-punctuation">.</span><span style="font-family: courier new,monospace;" class="js-variable">DecimalFormat</span><span style="font-family: courier new,monospace;" class="js-punctuation">( </span><span style="font-family: courier new,monospace;" class="js-string">"00000000+;00000000-" </span><span style="font-family: courier new,monospace;" class="js-punctuation">).</span><span style="font-family: courier new,monospace;" class="js-variable">parse</span><span style="font-family: courier new,monospace;" class="js-punctuation">( </span><span style="font-family: courier new,monospace;" class="js-variable">number </span><span style="font-family: courier new,monospace;" class="js-punctuation">) / 100</span><br>
<span class="js-punctuation"></span></blockquote><span class="js-punctuation"><br>And ignore my regexp madness from before...<br><br>Tim<br><br></span><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 3:29 PM, Tim Yates <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285832&i=0" target="_top" rel="nofollow">tim.yates@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There's probably a better way, but this works (I think)<br><br><div style="margin-left: 40px;">
<span style="font-family: courier new,monospace;">cobolInt </span><span style="font-family: courier new,monospace;">= </span><span style="font-family: courier new,monospace;">'12345678-'</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">m </span><span style="font-family: courier new,monospace;">= </span><span style="font-family: courier new,monospace;">cobolInt </span><span style="font-family: courier new,monospace;">=</span><span style="font-family: courier new,monospace;">~ </span><span style="font-family: courier new,monospace;">/</span><span style="font-family: courier new,monospace;">([</span><span style="font-family: courier new,monospace;">0</span><span style="font-family: courier new,monospace;">-</span><span style="font-family: courier new,monospace;">9</span><span style="font-family: courier new,monospace;">]</span><span style="font-family: courier new,monospace;">+</span><span style="font-family: courier new,monospace;">)([</span><span style="font-family: courier new,monospace;">-</span><span style="font-family: courier new,monospace;">]{</span><span style="font-family: courier new,monospace;">0</span><span style="font-family: courier new,monospace;">,</span><span style="font-family: courier new,monospace;">1</span><span style="font-family: courier new,monospace;">})</span><span style="font-family: courier new,monospace;">/</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">value </span><span style="font-family: courier new,monospace;">= </span><span style="font-family: courier new,monospace;">( ( </span><span style="font-family: courier new,monospace;">m</span><span style="font-family: courier new,monospace;">[</span><span style="font-family: courier new,monospace;">0</span><span style="font-family: courier new,monospace;">][ </span><span style="font-family: courier new,monospace;">1 </span><span style="font-family: courier new,monospace;">] </span><span style="font-family: courier new,monospace;">as </span><span style="font-family: courier new,monospace;">Integer </span><span style="font-family: courier new,monospace;">) </span><span style="font-family: courier new,monospace;">* </span><span style="font-family: courier new,monospace;">Integer</span><span style="font-family: courier new,monospace;">.</span><span style="font-family: courier new,monospace;">parseInt</span><span style="font-family: courier new,monospace;">( </span><span style="font-family: courier new,monospace;">"${m[0][2]}1" </span><span style="font-family: courier new,monospace;">) ) </span><span style="font-family: courier new,monospace;">/ </span><span style="font-family: courier new,monospace;">100</span><br>
<span></span></div><span><br>Tim<br></span><div><div></div><div class="h5"><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 3:19 PM, Spark43502 <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285832&i=1" target="_top" rel="nofollow">root@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
How do I convert a COBOL trailing sign numeric to a BigDecimal?<br>
<br>
ie. trailing sign numeric = 12345678-<br>
I want to convert this to a BigDecimal with 2 decimal positions =<br>
-123456.78<br>
<br>
I was able to successfully convert from a BigDecimal to COBOL trailing sign<br>
format using NumberFormat and DecimalFormat with the formatting string<br>
'00000000+;00000000-'<br>
<br></blockquote></div></div></div></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26285678as Integer doesn't work with GStringImpl?2009-11-10T07:43:50Z2009-11-10T07:43:50ZTim YatesHiya, is this JIRA worthy?<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; font-family: courier new,monospace;" class="gmail_quote">"-1" as Integer<br>
</blockquote><br>returns -1<br><br>however:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; font-family: courier new,monospace;" class="gmail_quote">a = '-1'<br>
"$a" as Integer<br></blockquote><br>gives<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre style="display: block;" id="stacktrace" class="border hidden">
<span style="font-family: courier new,monospace;">org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '-1' with class 'org.codehaus.groovy.runtime.GStringImpl' to class 'java.lang.Integer'</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> at Script1.run(Script1.groovy:2)</span><br></pre></blockquote>But you can do it with:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; font-family: courier new,monospace;" class="gmail_quote">
a = '-1'<br>
( "$a" as String ) as Integer<br></blockquote>
<br>Tim<br>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26285436Re: Converting COBOL trailing sign numeric to BigDecimal2009-11-10T07:29:50Z2009-11-10T07:29:50ZTim YatesThere's probably a better way, but this works (I think)<br><br><div style="margin-left: 40px;"><span style="font-family: courier new,monospace;" class="js-variable">cobolInt </span><span style="font-family: courier new,monospace;" class="js-operator">= </span><span style="font-family: courier new,monospace;" class="js-string">'12345678-'</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;" class="js-variable">m </span><span style="font-family: courier new,monospace;" class="js-operator">= </span><span style="font-family: courier new,monospace;" class="js-variable">cobolInt </span><span style="font-family: courier new,monospace;" class="js-operator">=</span><span style="font-family: courier new,monospace;" class="js-variable">~ </span><span style="font-family: courier new,monospace;" class="js-operator">/</span><span style="font-family: courier new,monospace;" class="js-punctuation">([</span><span style="font-family: courier new,monospace;" class="js-atom">0</span><span style="font-family: courier new,monospace;" class="js-operator">-</span><span style="font-family: courier new,monospace;" class="js-atom">9</span><span style="font-family: courier new,monospace;" class="js-punctuation">]</span><span style="font-family: courier new,monospace;" class="js-operator">+</span><span style="font-family: courier new,monospace;" class="js-punctuation">)([</span><span style="font-family: courier new,monospace;" class="js-operator">-</span><span style="font-family: courier new,monospace;" class="js-punctuation">]{</span><span style="font-family: courier new,monospace;" class="js-atom">0</span><span style="font-family: courier new,monospace;" class="js-punctuation">,</span><span style="font-family: courier new,monospace;" class="js-atom">1</span><span style="font-family: courier new,monospace;" class="js-punctuation">})</span><span style="font-family: courier new,monospace;" class="js-operator">/</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;" class="js-variable">value </span><span style="font-family: courier new,monospace;" class="js-operator">= </span><span style="font-family: courier new,monospace;" class="js-punctuation">( ( </span><span style="font-family: courier new,monospace;" class="js-variable">m</span><span style="font-family: courier new,monospace;" class="js-punctuation">[</span><span style="font-family: courier new,monospace;" class="js-atom">0</span><span style="font-family: courier new,monospace;" class="js-punctuation">][ </span><span style="font-family: courier new,monospace;" class="js-atom">1 </span><span style="font-family: courier new,monospace;" class="js-punctuation">] </span><span style="font-family: courier new,monospace;" class="js-keyword">as </span><span style="font-family: courier new,monospace;" class="js-variable">Integer </span><span style="font-family: courier new,monospace;" class="js-punctuation">) </span><span style="font-family: courier new,monospace;" class="js-operator">* </span><span style="font-family: courier new,monospace;" class="js-variable">Integer</span><span style="font-family: courier new,monospace;" class="js-punctuation">.</span><span style="font-family: courier new,monospace;" class="js-variable">parseInt</span><span style="font-family: courier new,monospace;" class="js-punctuation">( </span><span style="font-family: courier new,monospace;" class="js-string">"${m[0][2]}1" </span><span style="font-family: courier new,monospace;" class="js-punctuation">) ) </span><span style="font-family: courier new,monospace;" class="js-operator">/ </span><span style="font-family: courier new,monospace;" class="js-atom">100</span><br>
<span class="js-atom"></span></div><span class="js-atom"><br>Tim<br></span><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 3:19 PM, Spark43502 <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285436&i=0" target="_top" rel="nofollow">root@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
How do I convert a COBOL trailing sign numeric to a BigDecimal?<br>
<br>
ie. trailing sign numeric = 12345678-<br>
I want to convert this to a BigDecimal with 2 decimal positions =<br>
-123456.78<br>
<br>
I was able to successfully convert from a BigDecimal to COBOL trailing sign<br>
format using NumberFormat and DecimalFormat with the formatting string<br>
'00000000+;00000000-'<br>
<br>
--<br>
View this message in context: <a href="http://old.nabble.com/Converting-COBOL-trailing-sign-numeric-to-BigDecimal-tp26284851p26284851.html" target="_blank" rel="nofollow">http://old.nabble.com/Converting-COBOL-trailing-sign-numeric-to-BigDecimal-tp26284851p26284851.html</a><br>
Sent from the groovy - user mailing list archive at Nabble.com.<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this list, please visit:<br>
<br>
<a href="http://xircles.codehaus.org/manage_email" target="_blank" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>
<br>
<br>
</blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26284851Converting COBOL trailing sign numeric to BigDecimal2009-11-10T07:19:02Z2009-11-10T07:19:02ZSpark43502How do I convert a COBOL trailing sign numeric to a BigDecimal?
<br><br>ie. trailing sign numeric = 12345678-
<br>I want to convert this to a BigDecimal with 2 decimal positions = -123456.78
<br><br>I was able to successfully convert from a BigDecimal to COBOL trailing sign format using NumberFormat and DecimalFormat with the formatting string '00000000+;00000000-'
<br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26285051Re: Handling RESTClient post() responses with no content-type or body.2009-11-10T07:09:31Z2009-11-10T07:09:31ZTom NicholsHi Jon,
<br><br>Are you sure you got an updated snapshot? It was published on Nov
<br>6th. You can get the timestamped version of the JAR here:
<br><a href="http://snapshots.repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0-SNAPSHOT/http-builder-0.5.0-20091107.042829-12.jar" target="_top" rel="nofollow">http://snapshots.repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0-SNAPSHOT/http-builder-0.5.0-20091107.042829-12.jar</a><br><br>I'm surprised that you'd see _no_ change in the behavior. Although
<br>part of the problem is I'm trying to fix this "blind," so to speak,
<br>without being able to reproduce it myself. Can you point me to a
<br>public GeoServer instance, or your dev server which I can use to test
<br>things while I develop the fix? I'm certain this is not just
<br>GeoServer's fault. While uncommon, it's not a requirement for a
<br>response to contain a body. Therefore RESTClient should be able to
<br>handle the case and I'm more than willing to work with you to get it
<br>fixed in the HTTPBuilder code.
<br><br>Can you please also verify that the exception stack trace is
<br>identical, once you've verified that you're using an updated snapshot?
<br> Thanks.
<br><br>-Tom
<br><br>On Tue, Nov 10, 2009 at 9:29 AM, Jon Britton
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285051&i=0" target="_top" rel="nofollow">man_kills_everything@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> Hi Tom,
<br>>
<br>> I've just tried again with 0.5.0-SNAPSHOT and my original code (the
<br>> RESTClient one) and I'm still getting the same exceptions
<br>> (NullPointerException, IllegalArgumentException and ResponseParseException).
<br>>
<br>> Again, here is the code I'm using:
<br>>
<br>> def createWorkspace(workspace, geoserverUrl, user, pass){
<br>> // setup the restclient
<br>> def geoserver = new RESTClient(geoserverUrl)
<br>> // do the authing
<br>> geoserver.auth.basic user, pass
<br>> // post it
<br>> def res = geoserver.post( path: "/geoserver/rest/workspaces",
<br>> requestContentType: XML,
<br>> body: "<workspace><name>${workspace}</name></workspace>"
<br>> ).getStatus()
<br>> }
<br>>
<br>> I guess this is all GeoServers fault?
<br>>
<br>> Jon
<br>>
<br>>
<br>> Tom Nichols wrote:
<br>>>
<br>>> Hi Jon,
<br>>>
<br>>> I just deployed a new 0.5.0-SNAPSHOT release; this should fix the
<br>>> empty response body issue. For RESTClient responses, response.data
<br>>> should simply be null. But all header/ response code information
<br>>> should be readily available. Please give it a try and let me know
<br>>> what you find.
<br>>>
<br>>> Thanks.
<br>>> -Tom
<br>>>
<br>>>
<br>>>
<br>>> On Fri, Nov 6, 2009 at 11:11 AM, Tom Nichols <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285051&i=1" target="_top" rel="nofollow">tmnichols@...</a>> wrote:
<br>>>> hmm, I'm not sure what to tell you; I just copied your example into a
<br>>>> Groovy console and ran it, and I didn't get the MissingMethodException
<br>>>> that you're seeing there, using 0.5.0-RC2.
<br>>>>
<br>>>> Try this variation:
<br>>>> def http = new groovyx.net.http.HTTPBuilder(
<br>>>> "<a href="http://localhost:8080/geoserver/rest/workspaces" target="_top" rel="nofollow">http://localhost:8080/geoserver/rest/workspaces</a>" )
<br>>>> http.handler.SUCCESS = { return it }
<br>>>>
<br>>>> def response = http.post( headers:['Content-Type': 'text/xml'],
<br>>>> body: "<workspace><name>bob</name></workspace>" )
<br>>>>
<br>>>> assert response.status == 201
<br>>>>
<br>>>>
<br>>>>
<br>>>> 2009/11/6 Jon Britton <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285051&i=2" target="_top" rel="nofollow">man_kills_everything@...</a>>:
<br>>>>>
<br>>>>> Hi again, I'm just trying your example without using RESTClient but it
<br>>>>> doesn't work. My code is below, followed by the error I receive. What's
<br>>>>> could be causing this?
<br>>>>>
<br>>>>> Thanks,
<br>>>>>
<br>>>>> Jon
<br>>>>>
<br>>>>> CODE:
<br>>>>>
<br>>>>> def createWorkspace(def wsName, def geoserverUrl, def user, def pass){
<br>>>>> def http = new HTTPBuilder(
<br>>>>> "${geoserverUrl}/geoserver/rest/workspaces" )
<br>>>>> http.handler.SUCCESS = { return it }
<br>>>>>
<br>>>>> def response = http.request( POST, XML ) {
<br>>>>> body = "<workspace><name>${wsName}</name></workspace>"
<br>>>>> }
<br>>>>>
<br>>>>> assert response.status == 201
<br>>>>> }
<br>>>>>
<br>>>>> //Call method
<br>>>>> def code = createWorkspace("hello1",
<br>>>>> "<a href="http://admin:geoserver@localhost:8080/" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/</a>", "admin", "geoserver")
<br>>>>>
<br>>>>> OUTPUT:
<br>>>>>
<br>>>>> Caught: groovy.lang.MissingMethodException: No signature of method:
<br>>>>> groovyx.net.http.HTTPBuilder.request() is applicable
<br>>>>> for argument types: (groovyx.net.http.Method,
<br>>>>> groovyx.net.http.ContentType,
<br>>>>> uk.ac.glam.rest.GroovyTest$_createWorkspace
<br>>>>> _closure2) values: [POST, application/xml,
<br>>>>> uk.ac.glam.rest.GroovyTest$_createWorkspace_closure2@2fb002]
<br>>>>> at
<br>>>>> uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:54)
<br>>>>> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:70)
<br>>>>>
<br>>>>>
<br>>>>>
<br>>>>> Tom Nichols wrote:
<br>>>>>>
<br>>>>>> Nope, you're right; in that case, the response object should be
<br>>>>>> available, and the 'data' property (which is the parsed response body)
<br>>>>>> should just be null. Definitely a bug.
<br>>>>>>
<br>>>>>> However, after looking at the stack trace, I don't think you should be
<br>>>>>> getting an NPE but an IllegalArgumentException (this is still
<br>>>>>> erroneous in the case of RESTClient, but it's due to RESTClient's
<br>>>>>> underlying use of HTTPBuilder). What version of HTTPBuilder are you
<br>>>>>> using?
<br>>>>>>
<br>>>>>> In either case, the bug still stands; I'll start working on it
<br>>>>>> soon-ish. You can work around it for now by using the HTTPBuilder
<br>>>>>> class directly, which other than being slightly more verbose can do
<br>>>>>> the exact thing you're doing with RESTClient.
<br>>>>>>
<br>>>>>> import static groovyx.net.http.Method.POST
<br>>>>>> import static groovyx.net.http.ContentType.XML
<br>>>>>>
<br>>>>>> def http = new HTTPBuilder(
<br>>>>>> '<a href="http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'</a> )
<br>>>>>> http.handler.SUCCESS = { return it }
<br>>>>>>
<br>>>>>> def response = http.request( POST, XML ) {
<br>>>>>> body = '<workspace><name>dwins</name></workspace>'
<br>>>>>> }
<br>>>>>>
<br>>>>>> assert response.status == 201
<br>>>>>>
<br>>>>>>
<br>>>>>> Let me know if you have any trouble with the above example.
<br>>>>>> -Tom
<br>>>>>>
<br>>>>>>
<br>>>>>> On Thu, Nov 5, 2009 at 9:45 AM, Jon Britton
<br>>>>>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285051&i=3" target="_top" rel="nofollow">man_kills_everything@...</a>> wrote:
<br>>>>>>>
<br>>>>>>> Sorry, forgot the full stack trace:
<br>>>>>>>
<br>>>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.ParserRegistry getContentType
<br>>>>>>> WARNING: Could not parse content-type header in response
<br>>>>>>> java.lang.NullPointerException
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:153)
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>>>> Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>> at
<br>>>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.HTTPBuilder doRequest
<br>>>>>>> WARNING: Error parsing 'null' response
<br>>>>>>> java.lang.IllegalArgumentException: Could not parse content-type from
<br>>>>>>> response
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:157)
<br>>>>>>> at
<br>>>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>>>> Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>> at
<br>>>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
<br>>>>>>> Source)
<br>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>>>> at
<br>>>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>>>> Caught: groovyx.net.http.ResponseParseException: Created
<br>>>>>>> at
<br>>>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>>>
<br>>>>>>>
<br>>>>>>>
<br>>>>>>> Tom Nichols wrote:
<br>>>>>>>>
<br>>>>>>>> Hmm interesting. I was under the assumption that a POST response
<br>>>>>>>> should include _some_ sort of response body, but maybe that's not
<br>>>>>>>> technically required by the HTTP spec. If you can send me the
<br>>>>>>>> exception stack trace I'm sure I can fix it, but I can't tell you
<br>>>>>>>> what
<br>>>>>>>> you yourself can do until you give me some more details.
<br>>>>>>>>
<br>>>>>>>> Better yet, if you can file a JIRA here:
<br>>>>>>>> <a href="http://jira.codehaus.org/browse/GMOD" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GMOD</a><br>>>>>>>> that would be super awesome (put the bug under the "HTTPBuilder"
<br>>>>>>>> module). And If you really want to earn karma points, give enough of
<br>>>>>>>> an example that I can reproduce the error condition myself :) I
<br>>>>>>>> don't
<br>>>>>>>> konw if GeoServer has an open API, but if they do I can add it to the
<br>>>>>>>> unit tests.
<br>>>>>>>>
<br>>>>>>>> Thanks.
<br>>>>>>>> -Tom
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>> On Thu, Nov 5, 2009 at 9:22 AM, Jon Britton
<br>>>>>>>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26285051&i=4" target="_top" rel="nofollow">man_kills_everything@...</a>> wrote:
<br>>>>>>>>>
<br>>>>>>>>> Hi,
<br>>>>>>>>> I'm using RESTClient from the HTTP Builder module to send a POST
<br>>>>>>>>> request
<br>>>>>>>>> to
<br>>>>>>>>> GeoServer. However, the response to my request doesn't contain a
<br>>>>>>>>> content-type or body so I get the following followed by a number of
<br>>>>>>>>> exceptions:
<br>>>>>>>>>
<br>>>>>>>>> 05-Nov-2009 14:12:42 groovyx.net.http.ParserRegistry getContentType
<br>>>>>>>>> WARNING: Could not parse content-type header in response
<br>>>>>>>>>
<br>>>>>>>>> Followed by exceptions. How can I get around this? All I want from
<br>>>>>>>>> the
<br>>>>>>>>> response is the status code, I'm not interested in anything else.
<br>>>>>>>>> My
<br>>>>>>>>> code
<br>>>>>>>>> is shown below.
<br>>>>>>>>>
<br>>>>>>>>> Thanks,
<br>>>>>>>>>
<br>>>>>>>>> Jon
<br>>>>>>>>>
<br>>>>>>>>> Code:
<br>>>>>>>>>
<br>>>>>>>>> def createWorkspace(def wsName, def geoserverUrl, def user, def
<br>>>>>>>>> pass){
<br>>>>>>>>> // setup the restclient
<br>>>>>>>>> def geoserver = new RESTClient(geoserverUrl)
<br>>>>>>>>> // do the authing
<br>>>>>>>>> geoserver.auth.basic user, pass
<br>>>>>>>>> // post it
<br>>>>>>>>> def res = geoserver.post( path: "geoserver/rest/workspaces",
<br>>>>>>>>> requestContentType: XML,
<br>>>>>>>>> body: "<workspace><name>${wsName}</name></workspace>"
<br>>>>>>>>> )
<br>>>>>>>>> }
<br>>>>>>>>>
<br>>>>>>>>> def code = createWorkspace("hello", "<a href="http://localhost:8080/" target="_top" rel="nofollow">http://localhost:8080/</a>",
<br>>>>>>>>> "admin",
<br>>>>>>>>> "geoserver")
<br>>>>>>>>> --
<br>>>>>>>>> View this message in context:
<br>>>>>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html</a><br>>>>>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>> ---------------------------------------------------------------------
<br>>>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>>>
<br>>>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>>
<br>>>>>>>>
<br>>>>>>>> ---------------------------------------------------------------------
<br>>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>>
<br>>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>>
<br>>>>>>>
<br>>>>>>> --
<br>>>>>>> View this message in context:
<br>>>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html</a><br>>>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>>>
<br>>>>>>>
<br>>>>>>> ---------------------------------------------------------------------
<br>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>
<br>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>
<br>>>>>>>
<br>>>>>>>
<br>>>>>>
<br>>>>>> ---------------------------------------------------------------------
<br>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>
<br>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>
<br>>>>> --
<br>>>>> View this message in context:
<br>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html</a><br>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>
<br>>>>>
<br>>>>> ---------------------------------------------------------------------
<br>>>>> To unsubscribe from this list, please visit:
<br>>>>>
<br>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>
<br>>>>>
<br>>>>>
<br>>>>
<br>>>
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>>
<br>>>
<br>>
<br>> --
<br>> View this message in context: <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26284361.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26284361.html</a><br>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
</div><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26284713Re: On static compilation of Groovy2009-11-10T06:50:46Z2009-11-10T06:50:46ZJochen TheodorouMichael Baehr schrieb:
<br>> This reminds me of the discussion about having a joint compiler for
<br>> Java and Groovy.
<br>>
<br>> All the Groovy bigger heads were totally against it (do a search and
<br>> you will find a similar list of threads), 'til somebody by the name
<br>> Alex Tkachman just created one - and since then the project leads
<br>> declared it as the best thing since sliced bread.
<br><br>I was not against a joint compiler, I just had another idea of how to do
<br>it, because the current joint compiler cannot compile all cases. I
<br>suggested for example that using the eclipse compiler might be an
<br>option. But because Alex just did that the joint compiler proofed to
<br>handle enough cases after some problematic cases has been resolved.
<br><br>Currently transforms are the biggest problem for the joint compiler. And
<br>not all of these problems can be resolved with the joint compiler
<br>because of its nature. I still think the eclipse compiler might be a
<br>better solution in the end.
<br><br>> So Alex, just go for it - there are obviously enough people who would
<br>> want to have something like that.
<br><br>I always said that this is possible as transform. If Alex wants to write
<br>one, then he should do. Just if that then goes in groovy-core is a
<br>different thing. If Alex wants to makes a project/module for it and
<br>maintains it, then I sure would say this is good. From my experience
<br>Alex has not enough time to maintain something like that, so it should
<br>be more than only him. How about all the people that think that such a
<br>transform would be a good idea help Alex in developing something like that?
<br><br>bye blackdrag
<br><br>--
<br>Jochen "blackdrag" Theodorou
<br>The Groovy Project Tech Lead (<a href="http://groovy.codehaus.org" target="_top" rel="nofollow">http://groovy.codehaus.org</a>)
<br><a href="http://blackdragsview.blogspot.com/" target="_top" rel="nofollow">http://blackdragsview.blogspot.com/</a><br><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26284361Re: Handling RESTClient post() responses with no content-type or body.2009-11-10T06:29:08Z2009-11-10T06:29:08ZJon BrittonHi Tom,
<br><br>I've just tried again with 0.5.0-SNAPSHOT and my original code (the RESTClient one) and I'm still getting the same exceptions (NullPointerException, IllegalArgumentException and ResponseParseException).
<br><br>Again, here is the code I'm using:
<br><br>def createWorkspace(workspace, geoserverUrl, user, pass){
<br> // setup the restclient
<br> def geoserver = new RESTClient(geoserverUrl)
<br> // do the authing
<br> geoserver.auth.basic user, pass
<br> // post it
<br> def res = geoserver.post( path: "/geoserver/rest/workspaces",
<br> requestContentType: XML,
<br> body: "<workspace><name>${workspace}</name></workspace>"
<br> ).getStatus()
<br>}
<br><br>I guess this is all GeoServers fault?
<br><br>Jon
<br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Tom Nichols wrote:</div>
<div class="quote-message shrinkable-quote">Hi Jon,
<br><br>I just deployed a new 0.5.0-SNAPSHOT release; this should fix the
<br>empty response body issue. For RESTClient responses, response.data
<br>should simply be null. But all header/ response code information
<br>should be readily available. Please give it a try and let me know
<br>what you find.
<br><br>Thanks.
<br>-Tom
<br><br><br><br>On Fri, Nov 6, 2009 at 11:11 AM, Tom Nichols <tmnichols@gmail.com> wrote:
<br>> hmm, I'm not sure what to tell you; I just copied your example into a
<br>> Groovy console and ran it, and I didn't get the MissingMethodException
<br>> that you're seeing there, using 0.5.0-RC2.
<br>>
<br>> Try this variation:
<br>> def http = new groovyx.net.http.HTTPBuilder(
<br>> "<a href="http://localhost:8080/geoserver/rest/workspaces" target="_top" rel="nofollow">http://localhost:8080/geoserver/rest/workspaces</a>" )
<br>> http.handler.SUCCESS = { return it }
<br>>
<br>> def response = http.post( headers:['Content-Type': 'text/xml'],
<br>> body: "<workspace><name>bob</name></workspace>" )
<br>>
<br>> assert response.status == 201
<br>>
<br>>
<br>>
<br>> 2009/11/6 Jon Britton <man_kills_everything@hotmail.com>:
<br>>>
<br>>> Hi again, I'm just trying your example without using RESTClient but it
<br>>> doesn't work. My code is below, followed by the error I receive. What's
<br>>> could be causing this?
<br>>>
<br>>> Thanks,
<br>>>
<br>>> Jon
<br>>>
<br>>> CODE:
<br>>>
<br>>> def createWorkspace(def wsName, def geoserverUrl, def user, def pass){
<br>>> def http = new HTTPBuilder( "${geoserverUrl}/geoserver/rest/workspaces" )
<br>>> http.handler.SUCCESS = { return it }
<br>>>
<br>>> def response = http.request( POST, XML ) {
<br>>> body = "<workspace><name>${wsName}</name></workspace>"
<br>>> }
<br>>>
<br>>> assert response.status == 201
<br>>> }
<br>>>
<br>>> //Call method
<br>>> def code = createWorkspace("hello1",
<br>>> "<a href="http://admin:geoserver@localhost:8080/" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/</a>", "admin", "geoserver")
<br>>>
<br>>> OUTPUT:
<br>>>
<br>>> Caught: groovy.lang.MissingMethodException: No signature of method:
<br>>> groovyx.net.http.HTTPBuilder.request() is applicable
<br>>> for argument types: (groovyx.net.http.Method, groovyx.net.http.ContentType,
<br>>> uk.ac.glam.rest.GroovyTest$_createWorkspace
<br>>> _closure2) values: [POST, application/xml,
<br>>> uk.ac.glam.rest.GroovyTest$_createWorkspace_closure2@2fb002]
<br>>> at uk.ac.glam.rest.GroovyTest.createWorkspace(GroovyTest.groovy:54)
<br>>> at uk.ac.glam.rest.GroovyTest.run(GroovyTest.groovy:70)
<br>>>
<br>>>
<br>>>
<br>>> Tom Nichols wrote:
<br>>>>
<br>>>> Nope, you're right; in that case, the response object should be
<br>>>> available, and the 'data' property (which is the parsed response body)
<br>>>> should just be null. Definitely a bug.
<br>>>>
<br>>>> However, after looking at the stack trace, I don't think you should be
<br>>>> getting an NPE but an IllegalArgumentException (this is still
<br>>>> erroneous in the case of RESTClient, but it's due to RESTClient's
<br>>>> underlying use of HTTPBuilder). What version of HTTPBuilder are you
<br>>>> using?
<br>>>>
<br>>>> In either case, the bug still stands; I'll start working on it
<br>>>> soon-ish. You can work around it for now by using the HTTPBuilder
<br>>>> class directly, which other than being slightly more verbose can do
<br>>>> the exact thing you're doing with RESTClient.
<br>>>>
<br>>>> import static groovyx.net.http.Method.POST
<br>>>> import static groovyx.net.http.ContentType.XML
<br>>>>
<br>>>> def http = new HTTPBuilder(
<br>>>> '<a href="http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'" target="_top" rel="nofollow">http://admin:geoserver@localhost:8080/geoserver/rest/workspaces'</a> )
<br>>>> http.handler.SUCCESS = { return it }
<br>>>>
<br>>>> def response = http.request( POST, XML ) {
<br>>>> body = '<workspace><name>dwins</name></workspace>'
<br>>>> }
<br>>>>
<br>>>> assert response.status == 201
<br>>>>
<br>>>>
<br>>>> Let me know if you have any trouble with the above example.
<br>>>> -Tom
<br>>>>
<br>>>>
<br>>>> On Thu, Nov 5, 2009 at 9:45 AM, Jon Britton
<br>>>> <man_kills_everything@hotmail.com> wrote:
<br>>>>>
<br>>>>> Sorry, forgot the full stack trace:
<br>>>>>
<br>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.ParserRegistry getContentType
<br>>>>> WARNING: Could not parse content-type header in response
<br>>>>> java.lang.NullPointerException
<br>>>>> at
<br>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:153)
<br>>>>> at
<br>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>> at
<br>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>> at com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>> Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>> at
<br>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>> at
<br>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>> 05-Nov-2009 14:45:22 groovyx.net.http.HTTPBuilder doRequest
<br>>>>> WARNING: Error parsing 'null' response
<br>>>>> java.lang.IllegalArgumentException: Could not parse content-type from
<br>>>>> response
<br>>>>> at
<br>>>>> groovyx.net.http.ParserRegistry.getContentType(ParserRegistry.java:157)
<br>>>>> at
<br>>>>> groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:510)
<br>>>>> at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:460)
<br>>>>> at groovyx.net.http.RESTClient.post(RESTClient.java:140)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
<br>>>>> at
<br>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>> at com.example.jon.GroovyTest$createWorkspace.callCurrent(Unknown
<br>>>>> Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
<br>>>>> at
<br>>>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:163)
<br>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>> at
<br>>>>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:256)
<br>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:219)
<br>>>>> at groovy.lang.GroovyShell.run(GroovyShell.java:149)
<br>>>>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:494)
<br>>>>> at groovy.ui.GroovyMain.run(GroovyMain.java:309)
<br>>>>> at groovy.ui.GroovyMain.process(GroovyMain.java:295)
<br>>>>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112)
<br>>>>> at groovy.ui.GroovyMain.main(GroovyMain.java:93)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<br>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
<br>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
<br>>>>> at
<br>>>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
<br>>>>> at
<br>>>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
<br>>>>> Caught: groovyx.net.http.ResponseParseException: Created
<br>>>>> at
<br>>>>> com.example.jon.GroovyTest.createWorkspace(GroovyTest.groovy:45)
<br>>>>> at com.example.jon.GroovyTest.run(GroovyTest.groovy:60)
<br>>>>>
<br>>>>>
<br>>>>>
<br>>>>> Tom Nichols wrote:
<br>>>>>>
<br>>>>>> Hmm interesting. I was under the assumption that a POST response
<br>>>>>> should include _some_ sort of response body, but maybe that's not
<br>>>>>> technically required by the HTTP spec. If you can send me the
<br>>>>>> exception stack trace I'm sure I can fix it, but I can't tell you what
<br>>>>>> you yourself can do until you give me some more details.
<br>>>>>>
<br>>>>>> Better yet, if you can file a JIRA here:
<br>>>>>> <a href="http://jira.codehaus.org/browse/GMOD" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GMOD</a><br>>>>>> that would be super awesome (put the bug under the "HTTPBuilder"
<br>>>>>> module). And If you really want to earn karma points, give enough of
<br>>>>>> an example that I can reproduce the error condition myself :) I don't
<br>>>>>> konw if GeoServer has an open API, but if they do I can add it to the
<br>>>>>> unit tests.
<br>>>>>>
<br>>>>>> Thanks.
<br>>>>>> -Tom
<br>>>>>>
<br>>>>>>
<br>>>>>> On Thu, Nov 5, 2009 at 9:22 AM, Jon Britton
<br>>>>>> <man_kills_everything@hotmail.com> wrote:
<br>>>>>>>
<br>>>>>>> Hi,
<br>>>>>>> I'm using RESTClient from the HTTP Builder module to send a POST
<br>>>>>>> request
<br>>>>>>> to
<br>>>>>>> GeoServer. However, the response to my request doesn't contain a
<br>>>>>>> content-type or body so I get the following followed by a number of
<br>>>>>>> exceptions:
<br>>>>>>>
<br>>>>>>> 05-Nov-2009 14:12:42 groovyx.net.http.ParserRegistry getContentType
<br>>>>>>> WARNING: Could not parse content-type header in response
<br>>>>>>>
<br>>>>>>> Followed by exceptions. How can I get around this? All I want from
<br>>>>>>> the
<br>>>>>>> response is the status code, I'm not interested in anything else. My
<br>>>>>>> code
<br>>>>>>> is shown below.
<br>>>>>>>
<br>>>>>>> Thanks,
<br>>>>>>>
<br>>>>>>> Jon
<br>>>>>>>
<br>>>>>>> Code:
<br>>>>>>>
<br>>>>>>> def createWorkspace(def wsName, def geoserverUrl, def user, def pass){
<br>>>>>>> // setup the restclient
<br>>>>>>> def geoserver = new RESTClient(geoserverUrl)
<br>>>>>>> // do the authing
<br>>>>>>> geoserver.auth.basic user, pass
<br>>>>>>> // post it
<br>>>>>>> def res = geoserver.post( path: "geoserver/rest/workspaces",
<br>>>>>>> requestContentType: XML,
<br>>>>>>> body: "<workspace><name>${wsName}</name></workspace>"
<br>>>>>>> )
<br>>>>>>> }
<br>>>>>>>
<br>>>>>>> def code = createWorkspace("hello", "<a href="http://localhost:8080/" target="_top" rel="nofollow">http://localhost:8080/</a>", "admin",
<br>>>>>>> "geoserver")
<br>>>>>>> --
<br>>>>>>> View this message in context:
<br>>>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215319.html</a><br>>>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>>>
<br>>>>>>>
<br>>>>>>> ---------------------------------------------------------------------
<br>>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>>
<br>>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>>
<br>>>>>>>
<br>>>>>>>
<br>>>>>>
<br>>>>>> ---------------------------------------------------------------------
<br>>>>>> To unsubscribe from this list, please visit:
<br>>>>>>
<br>>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>>
<br>>>>>
<br>>>>> --
<br>>>>> View this message in context:
<br>>>>> <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26215728.html</a><br>>>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>>>
<br>>>>>
<br>>>>> ---------------------------------------------------------------------
<br>>>>> To unsubscribe from this list, please visit:
<br>>>>>
<br>>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>>
<br>>>>>
<br>>>>>
<br>>>>
<br>>>> ---------------------------------------------------------------------
<br>>>> To unsubscribe from this list, please visit:
<br>>>>
<br>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>
<br>>>>
<br>>>>
<br>>>>
<br>>>
<br>>> --
<br>>> View this message in context: <a href="http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html" target="_top" rel="nofollow">http://old.nabble.com/Handling-RESTClient-post%28%29-responses-with-no-content-type-or-body.-tp26215319p26230809.html</a><br>>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>>
<br>>>
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>>
<br>>
<br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br></div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26284078Re: getClass() and @Mixin2009-11-10T06:10:11Z2009-11-10T06:10:11ZRoshan Dawrani-2This issue is already fixed in 1.7 (since beta-1, I guess) (However 1.6.6 still retains the behavior you are seeing)<br><br>Some related discussion can be found here: <a href="http://groovy.markmail.org/message/ezquvigs3q3fbpk7?q=jaxb+mixin" target="_top" rel="nofollow">http://groovy.markmail.org/message/ezquvigs3q3fbpk7?q=jaxb+mixin</a><br>
<br>Basically, now the methods of class Object are excluded from being forwarded to mixed-in class (except toString())<br><br>-- Roshan<br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 7:20 PM, Marc Guillemot <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26284078&i=0" target="_top" rel="nofollow">mguillemot@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I'm not sure if it is a known problem or not as I couldn't find any issue related to that.<br>
<br>
getClass() is not resolved against the real class but against the @Mixin class:<br>
<br>
// ---------------------------------------------<br>
class A {}<br>
<br>
@Mixin ([A])<br>
class B {<br>
def foo() { assert B == this.class }<br>
}<br>
<br>
new B().foo()<br>
// ---------------------------------------------<br>
<br>
Should I open an issue for it?<br>
<br>
A workaround seems to use this.metaClass.theClass. I'm not sure how safe it is.<br>
<br>
Cheers,<br>
Marc.<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this list, please visit:<br>
<br>
<a href="http://xircles.codehaus.org/manage_email" target="_blank" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>
<br>
<br>
</blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26283930Re: On static compilation of Groovy2009-11-10T06:03:22Z2009-11-10T06:03:22ZMichael Baehr-2Thought so ... ;-)
<br><br>On 10. Nov 2009, at 8:59, Alex Tkachman wrote:
<br><div class='shrinkable-quote'><br>> Alex Tkachman?
<br>> Yes, I heard that name.
<br>>
<br>> On Tue, Nov 10, 2009 at 3:28 PM, Michael Baehr <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283930&i=0" target="_top" rel="nofollow">codex69@...</a>> wrote:
<br>>> This reminds me of the discussion about having a joint compiler for Java and Groovy.
<br>>>
<br>>> All the Groovy bigger heads were totally against it (do a search and you will find a similar list of threads), 'til somebody by the name Alex Tkachman just created one - and since then the project leads declared it as the best thing since sliced bread.
<br>>>
<br>>> So Alex, just go for it - there are obviously enough people who would want to have something like that.
<br>>>
<br>>> cu
<br>>>
<br>>> Michael
<br>>>
<br>>> On 10. Nov 2009, at 6:19, Robert Fischer wrote:
<br>>>
<br>>>>> All this idea of a "static groovy" mode has been debated so many times
<br>>>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>>>> points about it.
<br>>>>> Just a one minute search brought me numerous threads on the topics, on
<br>>>>> the challenges and issues about this static groovy idea:
<br>>>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>>>
<br>>>> Best. Rebuttal. EVAR.
<br>>>>
<br>>>>
<br>>>> ~~ Robert Fischer, Smokejumper IT Consulting.
<br>>>> Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br>>>>
<br>>>> Grails Expert Retainer Services
<br>>>> <a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br>>>>
<br>>>>
<br>>>> Guillaume Laforge wrote:
<br>>>>> On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283930&i=1" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>>>>>> In your article you make the assertion, "due to performance reasons Groovy is
<br>>>>>> almost useless today for multi-core programming" without giving any reasons or
<br>>>>>> data to defend the assertion. I can't think of why this assertion should
<br>>>>>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>>>>>> this holds for any number of threads and any number of cores. Why would
<br>>>>>> properly parallelized Groovy code be inappropriate for code that engages in
<br>>>>>> lots of IO, which is the bulk of what business oriented code does?
<br>>>>> Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>>>>> usually ridiculous compared to the time software waits for data to
<br>>>>> come up from the database. And optimizing the IO access is usually
<br>>>>> going to offer leaps in the scalability and/or performance of your
<br>>>>> code.
<br>>>>>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>>>>>> entirely transparent for end users, 2) It does not increase the complexity of
<br>>>>>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>>>>>> other features, and 3) It changes none of the semantics of current Groovy
<br>>>>>> code. I doubt those three things are possible, but I am willing to be proved
<br>>>>>> wrong.
<br>>>>> All this idea of a "static groovy" mode has been debated so many times
<br>>>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>>>> points about it.
<br>>>>> Just a one minute search brought me numerous threads on the topics, on
<br>>>>> the challenges and issues about this static groovy idea:
<br>>>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>>>> And I'm sure there are even older threads on the topic.
<br>>>>> But to answer your points: 1) It won't be transparent in the sense
<br>>>>> that you would have to demarcate the code that would be made "static"
<br>>>>> (not a bad thing per se, though), but then avoid mixing static /
<br>>>>> non-static code, otherwise you wouldn't be able to really know what is
<br>>>>> or what is not statically compiled. 2) Of course it'll increase the
<br>>>>> complexity of the compiler. More advanced / complex features means
<br>>>>> more complexity to deal with, more bugs, a longer time to get it
<br>>>>> right, less resource / time to work on other features. And 3) it'd
<br>>>>> definitely change the semantics of current Groovy code, as for
<br>>>>> instance, the method resolution in a static mode is different from a
<br>>>>> dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>>>>> calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>>>>> static vs non-static mode. Groovy choses the method according to the
<br>>>>> runtime type, a static mode wouldn't.
<br>>>>> So this is all far from seamless, transparent. In the end, it somehow
<br>>>>> means maintaining two compilers in one.
<br>>>>>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>>>>>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>>>>>> sometime in the future?
<br>>>>> It's still early to really tell, as "invokedynamic" is still a work in
<br>>>>> progress. But hopefully, some significant gains will come from it,
<br>>>>> although it's still difficult to know what the real gains will be till
<br>>>>> there's a definitive working version available and testable.
<br>>>>> But I'd much rather see efforts improving "dynamic Groovy"
<br>>>>> (performance, features, etc), than abandonning this idea and turning
<br>>>>> Groovy into Java plus some syntaxic sugar only.
<br>>>>>> Also, if the objections to static compiling that I raised above cannot be met
<br>>>>>> there are alternatives to speeding up Groovy code that seem easier to
<br>>>>>> implement but would give big speedups to performance critical code. One would
<br>>>>>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>>>>>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>>>>>> and Scala, so this doesn't provide anything that can't already be done, it
<br>>>>>> simply provides convenience to the programmer.
<br>>>>> The integration is pretty much seamless already.
<br>>>>> Adding a small Java class for a routine that needs to be speed up is so easy.
<br>>>>> Once you've got your project build using the groovyc compiler (Ant
<br>>>>> build, GMaven, Gradle, whatever), you usually don't have much work to
<br>>>>> do to joint-compile Groovy and Java together -- perhaps just a few
<br>>>>> lines to customize the javac call.
<br>>>>> The benefit also is it clearly demarcates what's statically-compiled
<br>>>>> (Java) and what's your dynamic code (Groovy).
<br>>>>>> [...]
<br>>>>
<br>>>> ---------------------------------------------------------------------
<br>>>> To unsubscribe from this list, please visit:
<br>>>>
<br>>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>>
<br>>>>
<br>>>
<br>>>
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
</div><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26283860Re: On static compilation of Groovy2009-11-10T05:59:34Z2009-11-10T05:59:34ZAlex TkachmanAlex Tkachman?
<br>Yes, I heard that name.
<br><br>On Tue, Nov 10, 2009 at 3:28 PM, Michael Baehr <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283860&i=0" target="_top" rel="nofollow">codex69@...</a>> wrote:
<div class='shrinkable-quote'><br>> This reminds me of the discussion about having a joint compiler for Java and Groovy.
<br>>
<br>> All the Groovy bigger heads were totally against it (do a search and you will find a similar list of threads), 'til somebody by the name Alex Tkachman just created one - and since then the project leads declared it as the best thing since sliced bread.
<br>>
<br>> So Alex, just go for it - there are obviously enough people who would want to have something like that.
<br>>
<br>> cu
<br>>
<br>> Michael
<br>>
<br>> On 10. Nov 2009, at 6:19, Robert Fischer wrote:
<br>>
<br>>> > All this idea of a "static groovy" mode has been debated so many times
<br>>> > in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>> > points about it.
<br>>> > Just a one minute search brought me numerous threads on the topics, on
<br>>> > the challenges and issues about this static groovy idea:
<br>>> > <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>> > <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>> > <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>> > <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>> > <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>> > <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>> > <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>>
<br>>> Best. Rebuttal. EVAR.
<br>>>
<br>>>
<br>>> ~~ Robert Fischer, Smokejumper IT Consulting.
<br>>> Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br>>>
<br>>> Grails Expert Retainer Services
<br>>> <a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br>>>
<br>>>
<br>>> Guillaume Laforge wrote:
<br>>>> On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283860&i=1" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>>>>> In your article you make the assertion, "due to performance reasons Groovy is
<br>>>>> almost useless today for multi-core programming" without giving any reasons or
<br>>>>> data to defend the assertion. I can't think of why this assertion should
<br>>>>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>>>>> this holds for any number of threads and any number of cores. Why would
<br>>>>> properly parallelized Groovy code be inappropriate for code that engages in
<br>>>>> lots of IO, which is the bulk of what business oriented code does?
<br>>>> Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>>>> usually ridiculous compared to the time software waits for data to
<br>>>> come up from the database. And optimizing the IO access is usually
<br>>>> going to offer leaps in the scalability and/or performance of your
<br>>>> code.
<br>>>>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>>>>> entirely transparent for end users, 2) It does not increase the complexity of
<br>>>>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>>>>> other features, and 3) It changes none of the semantics of current Groovy
<br>>>>> code. I doubt those three things are possible, but I am willing to be proved
<br>>>>> wrong.
<br>>>> All this idea of a "static groovy" mode has been debated so many times
<br>>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>>> points about it.
<br>>>> Just a one minute search brought me numerous threads on the topics, on
<br>>>> the challenges and issues about this static groovy idea:
<br>>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>>> And I'm sure there are even older threads on the topic.
<br>>>> But to answer your points: 1) It won't be transparent in the sense
<br>>>> that you would have to demarcate the code that would be made "static"
<br>>>> (not a bad thing per se, though), but then avoid mixing static /
<br>>>> non-static code, otherwise you wouldn't be able to really know what is
<br>>>> or what is not statically compiled. 2) Of course it'll increase the
<br>>>> complexity of the compiler. More advanced / complex features means
<br>>>> more complexity to deal with, more bugs, a longer time to get it
<br>>>> right, less resource / time to work on other features. And 3) it'd
<br>>>> definitely change the semantics of current Groovy code, as for
<br>>>> instance, the method resolution in a static mode is different from a
<br>>>> dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>>>> calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>>>> static vs non-static mode. Groovy choses the method according to the
<br>>>> runtime type, a static mode wouldn't.
<br>>>> So this is all far from seamless, transparent. In the end, it somehow
<br>>>> means maintaining two compilers in one.
<br>>>>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>>>>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>>>>> sometime in the future?
<br>>>> It's still early to really tell, as "invokedynamic" is still a work in
<br>>>> progress. But hopefully, some significant gains will come from it,
<br>>>> although it's still difficult to know what the real gains will be till
<br>>>> there's a definitive working version available and testable.
<br>>>> But I'd much rather see efforts improving "dynamic Groovy"
<br>>>> (performance, features, etc), than abandonning this idea and turning
<br>>>> Groovy into Java plus some syntaxic sugar only.
<br>>>>> Also, if the objections to static compiling that I raised above cannot be met
<br>>>>> there are alternatives to speeding up Groovy code that seem easier to
<br>>>>> implement but would give big speedups to performance critical code. One would
<br>>>>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>>>>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>>>>> and Scala, so this doesn't provide anything that can't already be done, it
<br>>>>> simply provides convenience to the programmer.
<br>>>> The integration is pretty much seamless already.
<br>>>> Adding a small Java class for a routine that needs to be speed up is so easy.
<br>>>> Once you've got your project build using the groovyc compiler (Ant
<br>>>> build, GMaven, Gradle, whatever), you usually don't have much work to
<br>>>> do to joint-compile Groovy and Java together -- perhaps just a few
<br>>>> lines to customize the javac call.
<br>>>> The benefit also is it clearly demarcates what's statically-compiled
<br>>>> (Java) and what's your dynamic code (Groovy).
<br>>>>> [...]
<br>>>
<br>>> ---------------------------------------------------------------------
<br>>> To unsubscribe from this list, please visit:
<br>>>
<br>>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>>
<br>>>
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
</div><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26283729getClass() and @Mixin2009-11-10T05:50:27Z2009-11-10T05:50:27ZMarc GuillemotHi,
<br><br>I'm not sure if it is a known problem or not as I couldn't find any
<br>issue related to that.
<br><br>getClass() is not resolved against the real class but against the @Mixin
<br>class:
<br><br>// ---------------------------------------------
<br>class A {}
<br><br>@Mixin ([A])
<br>class B {
<br> def foo() { assert B == this.class }
<br>}
<br><br>new B().foo()
<br>// ---------------------------------------------
<br><br>Should I open an issue for it?
<br><br>A workaround seems to use this.metaClass.theClass. I'm not sure how safe
<br>it is.
<br><br>Cheers,
<br>Marc.
<br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26283441Re: On static compilation of Groovy2009-11-10T05:28:14Z2009-11-10T05:28:14ZMichael Baehr-2This reminds me of the discussion about having a joint compiler for Java and Groovy.
<br><br>All the Groovy bigger heads were totally against it (do a search and you will find a similar list of threads), 'til somebody by the name Alex Tkachman just created one - and since then the project leads declared it as the best thing since sliced bread.
<br><br>So Alex, just go for it - there are obviously enough people who would want to have something like that.
<br><br>cu
<br><br>Michael
<br><br>On 10. Nov 2009, at 6:19, Robert Fischer wrote:
<br><div class='shrinkable-quote'><br>> > All this idea of a "static groovy" mode has been debated so many times
<br>> > in the past on the mailing-list that I'm lazy reiterating all the bad
<br>> > points about it.
<br>> > Just a one minute search brought me numerous threads on the topics, on
<br>> > the challenges and issues about this static groovy idea:
<br>> > <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>> > <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>> > <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>> > <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>> > <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>> > <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>> > <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>
<br>> Best. Rebuttal. EVAR.
<br>>
<br>>
<br>> ~~ Robert Fischer, Smokejumper IT Consulting.
<br>> Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br>>
<br>> Grails Expert Retainer Services
<br>> <a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br>>
<br>>
<br>> Guillaume Laforge wrote:
<br>>> On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283441&i=0" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>>>> In your article you make the assertion, "due to performance reasons Groovy is
<br>>>> almost useless today for multi-core programming" without giving any reasons or
<br>>>> data to defend the assertion. I can't think of why this assertion should
<br>>>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>>>> this holds for any number of threads and any number of cores. Why would
<br>>>> properly parallelized Groovy code be inappropriate for code that engages in
<br>>>> lots of IO, which is the bulk of what business oriented code does?
<br>>> Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>>> usually ridiculous compared to the time software waits for data to
<br>>> come up from the database. And optimizing the IO access is usually
<br>>> going to offer leaps in the scalability and/or performance of your
<br>>> code.
<br>>>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>>>> entirely transparent for end users, 2) It does not increase the complexity of
<br>>>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>>>> other features, and 3) It changes none of the semantics of current Groovy
<br>>>> code. I doubt those three things are possible, but I am willing to be proved
<br>>>> wrong.
<br>>> All this idea of a "static groovy" mode has been debated so many times
<br>>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>>> points about it.
<br>>> Just a one minute search brought me numerous threads on the topics, on
<br>>> the challenges and issues about this static groovy idea:
<br>>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>>> And I'm sure there are even older threads on the topic.
<br>>> But to answer your points: 1) It won't be transparent in the sense
<br>>> that you would have to demarcate the code that would be made "static"
<br>>> (not a bad thing per se, though), but then avoid mixing static /
<br>>> non-static code, otherwise you wouldn't be able to really know what is
<br>>> or what is not statically compiled. 2) Of course it'll increase the
<br>>> complexity of the compiler. More advanced / complex features means
<br>>> more complexity to deal with, more bugs, a longer time to get it
<br>>> right, less resource / time to work on other features. And 3) it'd
<br>>> definitely change the semantics of current Groovy code, as for
<br>>> instance, the method resolution in a static mode is different from a
<br>>> dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>>> calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>>> static vs non-static mode. Groovy choses the method according to the
<br>>> runtime type, a static mode wouldn't.
<br>>> So this is all far from seamless, transparent. In the end, it somehow
<br>>> means maintaining two compilers in one.
<br>>>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>>>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>>>> sometime in the future?
<br>>> It's still early to really tell, as "invokedynamic" is still a work in
<br>>> progress. But hopefully, some significant gains will come from it,
<br>>> although it's still difficult to know what the real gains will be till
<br>>> there's a definitive working version available and testable.
<br>>> But I'd much rather see efforts improving "dynamic Groovy"
<br>>> (performance, features, etc), than abandonning this idea and turning
<br>>> Groovy into Java plus some syntaxic sugar only.
<br>>>> Also, if the objections to static compiling that I raised above cannot be met
<br>>>> there are alternatives to speeding up Groovy code that seem easier to
<br>>>> implement but would give big speedups to performance critical code. One would
<br>>>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>>>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>>>> and Scala, so this doesn't provide anything that can't already be done, it
<br>>>> simply provides convenience to the programmer.
<br>>> The integration is pretty much seamless already.
<br>>> Adding a small Java class for a routine that needs to be speed up is so easy.
<br>>> Once you've got your project build using the groovyc compiler (Ant
<br>>> build, GMaven, Gradle, whatever), you usually don't have much work to
<br>>> do to joint-compile Groovy and Java together -- perhaps just a few
<br>>> lines to customize the javac call.
<br>>> The benefit also is it clearly demarcates what's statically-compiled
<br>>> (Java) and what's your dynamic code (Groovy).
<br>>>> [...]
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
</div><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26283143Re: Much longer build times on Bamboo CI server2009-11-10T05:09:55Z2009-11-10T05:09:55ZRoshan Dawrani-2TeamCity groovy CI environment is also not having any increased times - increased build times on bamboo have nothing to do with my change then :-)<br><br>I wonder what is wrong on bamboo servers!<br><br><br><div class="gmail_quote">
On Tue, Nov 10, 2009 at 6:31 PM, Roshan Dawrani <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283143&i=0" target="_top" rel="nofollow">roshandawrani@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I should also add that locally I have not seen any such increase in the build times.<div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 6:30 PM, Roshan Dawrani <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283143&i=1" target="_top" rel="nofollow">roshandawrani@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>Since y'day, the build times on the Bamboo CI servers seems to have become much longer - normal builds that used to finish in ~8 minutes is now finishing in ~25 minutes and the trunk build with documentation ha gone up from ~35 minutes to ~100 minutes.<br>
<br>Anyone has any idea why? I am observing this change since the build that got triggered because of the GCL#parseClass() change that I introduced - but the only thing extra that it introduced was to append hashCode of script text string to the dummy file name that it generates.<br>
<br>That change should not be the cause of such a dramatic change in the build times, should it?<br><br>rgds,<br><font color="#888888">Roshan<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/groovy---dev-f11868.html" embed="fixTarget[11868]" target="_top" >groovy - dev</a></p>tag:old.nabble.com,2006:post-26283138Re: Much longer build times on Bamboo CI server2009-11-10T05:09:02Z2009-11-10T05:09:02ZGuillaume Laforge-2Perhaps the machine is totally overloaded.<div>I doubt it's a hashcode that changes the duration of the CI build so much!<br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 14:00, Roshan Dawrani <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283138&i=0" target="_top" rel="nofollow">roshandawrani@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>Since y'day, the build times on the Bamboo CI servers seems to have become much longer - normal builds that used to finish in ~8 minutes is now finishing in ~25 minutes and the trunk build with documentation ha gone up from ~35 minutes to ~100 minutes.<br>
<br>Anyone has any idea why? I am observing this change since the build that got triggered because of the GCL#parseClass() change that I introduced - but the only thing extra that it introduced was to append hashCode of script text string to the dummy file name that it generates.<br>
<br>That change should not be the cause of such a dramatic change in the build times, should it?<br><br>rgds,<br><font color="#888888">Roshan<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Guillaume Laforge<br>Groovy Project Manager<br>Head of Groovy Development at SpringSource<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br>
</div>
<p>From forum: <a href="http://old.nabble.com/groovy---dev-f11868.html" embed="fixTarget[11868]" target="_top" >groovy - dev</a></p>tag:old.nabble.com,2006:post-26283031Re: Much longer build times on Bamboo CI server2009-11-10T05:01:45Z2009-11-10T05:01:45ZRoshan Dawrani-2I should also add that locally I have not seen any such increase in the build times.<br><br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 6:30 PM, Roshan Dawrani <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26283031&i=0" target="_top" rel="nofollow">roshandawrani@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>Since y'day, the build times on the Bamboo CI servers seems to have become much longer - normal builds that used to finish in ~8 minutes is now finishing in ~25 minutes and the trunk build with documentation ha gone up from ~35 minutes to ~100 minutes.<br>
<br>Anyone has any idea why? I am observing this change since the build that got triggered because of the GCL#parseClass() change that I introduced - but the only thing extra that it introduced was to append hashCode of script text string to the dummy file name that it generates.<br>
<br>That change should not be the cause of such a dramatic change in the build times, should it?<br><br>rgds,<br><font color="#888888">Roshan<br>
</font></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/groovy---dev-f11868.html" embed="fixTarget[11868]" target="_top" >groovy - dev</a></p>tag:old.nabble.com,2006:post-26283020Much longer build times on Bamboo CI server2009-11-10T05:00:32Z2009-11-10T05:00:32ZRoshan Dawrani-2Hi,<br>Since y'day, the build times on the Bamboo CI servers seems to have become much longer - normal builds that used to finish in ~8 minutes is now finishing in ~25 minutes and the trunk build with documentation ha gone up from ~35 minutes to ~100 minutes.<br>
<br>Anyone has any idea why? I am observing this change since the build that got triggered because of the GCL#parseClass() change that I introduced - but the only thing extra that it introduced was to append hashCode of script text string to the dummy file name that it generates.<br>
<br>That change should not be the cause of such a dramatic change in the build times, should it?<br><br>rgds,<br>Roshan<br>
<p>From forum: <a href="http://old.nabble.com/groovy---dev-f11868.html" embed="fixTarget[11868]" target="_top" >groovy - dev</a></p>tag:old.nabble.com,2006:post-26282160[gant-scm] [10450] gant/trunk/build.gradle: Add back in the removed evaluate.2009-11-10T03:55:16Z2009-11-10T03:55:16Zrussel-9<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> [10450] gant/trunk/build.gradle: Add back in the removed evaluate.</title>
</head>
<body>
<div id="msg">
<dl>
<dt>Revision</dt> <dd><a href="http://fisheye.codehaus.org/changelog/gant/?cs=10450" target="_top" rel="nofollow">10450</a></dd>
<dt>Author</dt> <dd>russel</dd>
<dt>Date</dt> <dd>2009-11-10 05:55:16 -0600 (Tue, 10 Nov 2009)</dd>
</dl>
<h3>Log Message</h3>
<pre>Add back in the removed evaluate.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#ganttrunkbuildgradle" target="_top" rel="nofollow">gant/trunk/build.gradle</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="ganttrunkbuildgradle" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/build.gradle (10449 => 10450)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/build.gradle 2009-11-10 11:55:11 UTC (rev 10449)
+++ gant/trunk/build.gradle 2009-11-10 11:55:16 UTC (rev 10450)
</span><span class="lines">@@ -167,7 +167,7 @@
</span><span class="cx"> compileGroovy.doFirst { println ( '\n\tUsing Groovy version ' + groovyVersion + '\n' ) }
test.doFirst { groovyAntTaskTestVersionPropertyFile.write ( 'groovyAntTaskTestVersion = ' + groovyVersion ) }
def installDirectory = '/usr/share/gant'
</span><span class="rem">- try { installDirectory = gant_installPath }
</span><span class="add">+ try { installDirectory = evaluate ( '"' + gant_installPath + '"' ) }
</span><span class="cx"> catch ( MissingPropertyException mpe ) { /* Intentionally left blank. */ }
task install ( dependsOn : 'assemble' , description : "Install Gant (compiled against Groovy ${groovyVersion}) to ${installDirectory}." ) << {
def installBinDirectory = installDirectory + '/bin'
</span>
</pre>
</div>
</div>
</body>
</html>
<hr />
<p>
To unsubscribe from this list please visit:
</p>
<p>
<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>
<p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26282158[gant-scm] [10449] gant/trunk/build.gradle: Change the way in which gant_installPath is processed to deal with the case when it is not defined.2009-11-10T03:55:11Z2009-11-10T03:55:11Zrussel-9<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> [10449] gant/trunk/build.gradle: Change the way in which gant_installPath is processed to deal with the case when it is not defined.</title>
</head>
<body>
<div id="msg">
<dl>
<dt>Revision</dt> <dd><a href="http://fisheye.codehaus.org/changelog/gant/?cs=10449" target="_top" rel="nofollow">10449</a></dd>
<dt>Author</dt> <dd>russel</dd>
<dt>Date</dt> <dd>2009-11-10 05:55:11 -0600 (Tue, 10 Nov 2009)</dd>
</dl>
<h3>Log Message</h3>
<pre>Change the way in which gant_installPath is processed to deal with the case when it is not defined.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#ganttrunkbuildgradle" target="_top" rel="nofollow">gant/trunk/build.gradle</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="ganttrunkbuildgradle" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/build.gradle (10448 => 10449)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/build.gradle 2009-11-10 10:30:02 UTC (rev 10448)
+++ gant/trunk/build.gradle 2009-11-10 11:55:11 UTC (rev 10449)
</span><span class="lines">@@ -166,7 +166,9 @@
</span><span class="cx"> dependencies { groovy ( 'org.codehaus.groovy:groovy-all:' + groovyVersion ) }
compileGroovy.doFirst { println ( '\n\tUsing Groovy version ' + groovyVersion + '\n' ) }
test.doFirst { groovyAntTaskTestVersionPropertyFile.write ( 'groovyAntTaskTestVersion = ' + groovyVersion ) }
</span><span class="rem">- def installDirectory = evaluate ( '"' + ( gant_installPath ?: '/usr/share/gant' ) + '"' )
</span><span class="add">+ def installDirectory = '/usr/share/gant'
+ try { installDirectory = gant_installPath }
+ catch ( MissingPropertyException mpe ) { /* Intentionally left blank. */ }
</span><span class="cx"> task install ( dependsOn : 'assemble' , description : "Install Gant (compiled against Groovy ${groovyVersion}) to ${installDirectory}." ) << {
def installBinDirectory = installDirectory + '/bin'
def scriptsDirectory = '../scripts'
</span>
</pre>
</div>
</div>
</body>
</html>
<hr />
<p>
To unsubscribe from this list please visit:
</p>
<p>
<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>
<p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26281904Re: Licensing of the sample code and sample document for the online course2009-11-10T03:30:54Z2009-11-10T03:30:54ZGuillaume Laforge-2Hi!<div><br></div><div>True that there's no license specified on our online documentation.</div><div>I think we can safely consider it being licensed under the same terms as our codebase.</div><div>Ideally, I think we should probably have a look at the creative commons licenses which may be more appropriate for documentation content.</div>
<div>Anyhow, feel free to take inspiration from the online documentation for your online courses.</div><div><br></div><div>Guillaume<br><br><div class="gmail_quote">On Sun, Nov 8, 2009 at 23:41, Sang Shin <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26281904&i=0" target="_top" rel="nofollow">sangshinpassion@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
I am not sure if this is the right alias to ask this question. Hopefully someone<br>
knows the answer.<br>
<br>
My name is Sang Shin. I teach several free online courses through<br>
<a href="http://javapassion.com" target="_blank" rel="nofollow">javapassion.com</a> below.<br>
<br>
<a href="http://www.javapassion.com/" target="_blank" rel="nofollow">http://www.javapassion.com/</a><br>
<br>
I am planning to start "Groovy and Grails (with Passion!)" online course<br>
from Jan. 10th, 2010.<br>
<br>
Now I am wondering if I can borrow the code and document from the<br>
Groovy document site below (without violating any copyright). <br>
<a href="http://groovy.codehaus.org/Documentation" target="_blank" rel="nofollow">http://groovy.codehaus.org/Documentation</a><br>
<br>
Thanks in advance.<br>
<br>
-Sang<br>
<br>
-- <br>
---------------------------------------------------------------<br>
Sang Shin, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26281904&i=1" target="_top" rel="nofollow">sangshinpassion@...</a>, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26281904&i=2" target="_top" rel="nofollow">sang.shin@...</a><br>
<a href="http://www.javapassion.com/SangShinSchedule.html" target="_blank" rel="nofollow">http://www.javapassion.com/SangShinSchedule.html</a><br>
(Life is worth living... with Passion!)<br>
---------------------------------------------------------------<br>
"Ajax and Web 2.0 Programming" course starts from Sep. 7th, 2009<br>
<a href="http://www.javapassion.com/ajaxcodecamp/" target="_blank" rel="nofollow">http://www.javapassion.com/ajaxcodecamp/</a><br>
"Java EE Programming Advanced" course starts from Oct. 1st, 2009<br>
<a href="http://www.javapassion.com/javaee_advanced/" target="_blank" rel="nofollow">http://www.javapassion.com/javaee_advanced/</a><br>
---------------------------------------------------------------<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this list, please visit:<br>
<br>
<a href="http://xircles.codehaus.org/manage_email" target="_blank" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Guillaume Laforge<br>Groovy Project Manager<br>Head of Groovy Development at SpringSource<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br>
</div>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26281792Re: On static compilation of Groovy2009-11-10T03:19:07Z2009-11-10T03:19:07ZRobert Fischer > All this idea of a "static groovy" mode has been debated so many times
<br> > in the past on the mailing-list that I'm lazy reiterating all the bad
<br> > points about it.
<br> > Just a one minute search brought me numerous threads on the topics, on
<br> > the challenges and issues about this static groovy idea:
<br> > <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br> > <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br> > <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br> > <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br> > <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br> > <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br> > <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br> > <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br><br>Best. Rebuttal. EVAR.
<br><br><br>~~ Robert Fischer, Smokejumper IT Consulting.
<br>Enfranchised Mind Blog <a href="http://EnfranchisedMind.com/blog" target="_top" rel="nofollow">http://EnfranchisedMind.com/blog</a><br><br>Grails Expert Retainer Services
<br><a href="http://smokejumperit.com/grails-retainer/" target="_top" rel="nofollow">http://smokejumperit.com/grails-retainer/</a><br><br><br>Guillaume Laforge wrote:
<div class='shrinkable-quote'><br>> On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26281792&i=0" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>>> In your article you make the assertion, "due to performance reasons Groovy is
<br>>> almost useless today for multi-core programming" without giving any reasons or
<br>>> data to defend the assertion. I can't think of why this assertion should
<br>>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>>> this holds for any number of threads and any number of cores. Why would
<br>>> properly parallelized Groovy code be inappropriate for code that engages in
<br>>> lots of IO, which is the bulk of what business oriented code does?
<br>>
<br>> Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>> usually ridiculous compared to the time software waits for data to
<br>> come up from the database. And optimizing the IO access is usually
<br>> going to offer leaps in the scalability and/or performance of your
<br>> code.
<br>>
<br>>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>>> entirely transparent for end users, 2) It does not increase the complexity of
<br>>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>>> other features, and 3) It changes none of the semantics of current Groovy
<br>>> code. I doubt those three things are possible, but I am willing to be proved
<br>>> wrong.
<br>>
<br>> All this idea of a "static groovy" mode has been debated so many times
<br>> in the past on the mailing-list that I'm lazy reiterating all the bad
<br>> points about it.
<br>> Just a one minute search brought me numerous threads on the topics, on
<br>> the challenges and issues about this static groovy idea:
<br>> <a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br>> <a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br>> <a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br>> <a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br>> <a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>> <a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br>> <a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br>> <a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>> And I'm sure there are even older threads on the topic.
<br>>
<br>> But to answer your points: 1) It won't be transparent in the sense
<br>> that you would have to demarcate the code that would be made "static"
<br>> (not a bad thing per se, though), but then avoid mixing static /
<br>> non-static code, otherwise you wouldn't be able to really know what is
<br>> or what is not statically compiled. 2) Of course it'll increase the
<br>> complexity of the compiler. More advanced / complex features means
<br>> more complexity to deal with, more bugs, a longer time to get it
<br>> right, less resource / time to work on other features. And 3) it'd
<br>> definitely change the semantics of current Groovy code, as for
<br>> instance, the method resolution in a static mode is different from a
<br>> dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>> calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>> static vs non-static mode. Groovy choses the method according to the
<br>> runtime type, a static mode wouldn't.
<br>> So this is all far from seamless, transparent. In the end, it somehow
<br>> means maintaining two compilers in one.
<br>>
<br>>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>>> sometime in the future?
<br>>
<br>> It's still early to really tell, as "invokedynamic" is still a work in
<br>> progress. But hopefully, some significant gains will come from it,
<br>> although it's still difficult to know what the real gains will be till
<br>> there's a definitive working version available and testable.
<br>> But I'd much rather see efforts improving "dynamic Groovy"
<br>> (performance, features, etc), than abandonning this idea and turning
<br>> Groovy into Java plus some syntaxic sugar only.
<br>>
<br>>> Also, if the objections to static compiling that I raised above cannot be met
<br>>> there are alternatives to speeding up Groovy code that seem easier to
<br>>> implement but would give big speedups to performance critical code. One would
<br>>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>>> and Scala, so this doesn't provide anything that can't already be done, it
<br>>> simply provides convenience to the programmer.
<br>>
<br>> The integration is pretty much seamless already.
<br>> Adding a small Java class for a routine that needs to be speed up is so easy.
<br>> Once you've got your project build using the groovyc compiler (Ant
<br>> build, GMaven, Gradle, whatever), you usually don't have much work to
<br>> do to joint-compile Groovy and Java together -- perhaps just a few
<br>> lines to customize the javac call.
<br>> The benefit also is it clearly demarcates what's statically-compiled
<br>> (Java) and what's your dynamic code (Groovy).
<br>>
<br>>> [...]
<br>>
</div><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26281732[gant-scm] [jira] Assigned: (GANT-111) Exceptions caught in gant are wrapped in an exception that is not a descendant of ant's BuildException2009-11-10T03:13:55Z2009-11-10T03:13:55ZJIRA jira@codehaus.org<br> [ <a href="http://jira.codehaus.org/browse/GANT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Russel Winder reassigned GANT-111:
<br>----------------------------------
<br><br> Assignee: Russel Winder
<br><div class='shrinkable-quote'><br>> Exceptions caught in gant are wrapped in an exception that is not a descendant of ant's BuildException
<br>> ------------------------------------------------------------------------------------------------------
<br>>
<br>> Key: GANT-111
<br>> URL: <a href="http://jira.codehaus.org/browse/GANT-111" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-111</a><br>> Project: Gant
<br>> Issue Type: Bug
<br>> Components: Core
<br>> Affects Versions: 1.8.0
<br>> Reporter: Eric Van Dewoestine
<br>> Assignee: Russel Winder
<br>> Fix For: 1.9.0
<br>>
<br>> Attachments: gant_buildexception.diff
<br>>
<br>>
<br>> When an exception is raised and subsequently caught by gant, that exception is wrapped in a TargetExecutionException, which is not a descendant of ant's BuildException, and that exception is then thrown. This can be problematic when gant is invoked from ant since ant handles BuildExceptions differently than all other exception types.
<br>> When ant catches a BuildException it will suppress the stack trace associated with that exception (unless you add the -debug flag) and simply print a normal ant failure message that ant users should be accustom to. When ant catches the TargetExecutionException (or any non-BuildException descendant), it will print out its stack trace, which in turn will print the root exception stack trace leading to two very large stack traces dumped onto the screen.
<br>> A slightly worse case arises if the gant build file issues a call to ant.fail(message: "some message"), which will again result in the two very large stack traces printed, since the BuildException raised by the fail task is wrapped in a non-BuildException. Since ant.fail can be commonly used to abort a build and report useful information to the user, having that information buried in stack traces can severely affect the usability of the build file.
<br>> Attached is a patch which alters GantException to now subclass BuildException and adds a test case where the fail task is invoked in gant from a parent ant script.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>If you think it was sent incorrectly contact one of the administrators: <a href="http://jira.codehaus.org/secure/Administrators.jspa" target="_top" rel="nofollow">http://jira.codehaus.org/secure/Administrators.jspa</a><br>-
<br>For more information on JIRA, see: <a href="http://www.atlassian.com/software/jira" target="_top" rel="nofollow">http://www.atlassian.com/software/jira</a><br><br>
<br><br><hr/>
<br><p>
<br>To unsubscribe from this list please visit:
<br></p>
<br><p>
<br> <a href="<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>"><a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a></a>
<br><br><p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26281714[gant-scm] [jira] Resolved: (GANT-111) Exceptions caught in gant are wrapped in an exception that is not a descendant of ant's BuildException2009-11-10T03:11:55Z2009-11-10T03:11:55ZJIRA jira@codehaus.org<br> [ <a href="http://jira.codehaus.org/browse/GANT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Russel Winder resolved GANT-111.
<br>--------------------------------
<br><br> Resolution: Fixed
<br><br>Test and patch applied. All the Bazaar branches have been updated and the distributions and artefacts also.
<br><div class='shrinkable-quote'><br>> Exceptions caught in gant are wrapped in an exception that is not a descendant of ant's BuildException
<br>> ------------------------------------------------------------------------------------------------------
<br>>
<br>> Key: GANT-111
<br>> URL: <a href="http://jira.codehaus.org/browse/GANT-111" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-111</a><br>> Project: Gant
<br>> Issue Type: Bug
<br>> Components: Core
<br>> Affects Versions: 1.8.0
<br>> Reporter: Eric Van Dewoestine
<br>> Fix For: 1.9.0
<br>>
<br>> Attachments: gant_buildexception.diff
<br>>
<br>>
<br>> When an exception is raised and subsequently caught by gant, that exception is wrapped in a TargetExecutionException, which is not a descendant of ant's BuildException, and that exception is then thrown. This can be problematic when gant is invoked from ant since ant handles BuildExceptions differently than all other exception types.
<br>> When ant catches a BuildException it will suppress the stack trace associated with that exception (unless you add the -debug flag) and simply print a normal ant failure message that ant users should be accustom to. When ant catches the TargetExecutionException (or any non-BuildException descendant), it will print out its stack trace, which in turn will print the root exception stack trace leading to two very large stack traces dumped onto the screen.
<br>> A slightly worse case arises if the gant build file issues a call to ant.fail(message: "some message"), which will again result in the two very large stack traces printed, since the BuildException raised by the fail task is wrapped in a non-BuildException. Since ant.fail can be commonly used to abort a build and report useful information to the user, having that information buried in stack traces can severely affect the usability of the build file.
<br>> Attached is a patch which alters GantException to now subclass BuildException and adds a test case where the fail task is invoked in gant from a parent ant script.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>If you think it was sent incorrectly contact one of the administrators: <a href="http://jira.codehaus.org/secure/Administrators.jspa" target="_top" rel="nofollow">http://jira.codehaus.org/secure/Administrators.jspa</a><br>-
<br>For more information on JIRA, see: <a href="http://www.atlassian.com/software/jira" target="_top" rel="nofollow">http://www.atlassian.com/software/jira</a><br><br>
<br><br><hr/>
<br><p>
<br>To unsubscribe from this list please visit:
<br></p>
<br><p>
<br> <a href="<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>"><a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a></a>
<br><br><p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26281249[gant-scm] [10448] gant/trunk: Applied the change from GANT-111.2009-11-10T02:30:02Z2009-11-10T02:30:02Zrussel-9<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> [10448] gant/trunk: Applied the change from GANT-111.</title>
</head>
<body>
<div id="msg">
<dl>
<dt>Revision</dt> <dd><a href="http://fisheye.codehaus.org/changelog/gant/?cs=10448" target="_top" rel="nofollow">10448</a></dd>
<dt>Author</dt> <dd>russel</dd>
<dt>Date</dt> <dd>2009-11-10 04:30:02 -0600 (Tue, 10 Nov 2009)</dd>
</dl>
<h3>Log Message</h3>
<pre>Applied the change from <a href="http://jira.codehaus.org/secure/ViewIssue.jspa?key=GANT-111" target="_top" rel="nofollow">GANT-111</a>.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#ganttrunkreleaseNotestxt" target="_top" rel="nofollow">gant/trunk/releaseNotes.txt</a></li>
<li><a href="#ganttrunksrcmaingroovygantGantExceptiongroovy" target="_top" rel="nofollow">gant/trunk/src/main/groovy/gant/GantException.groovy</a></li>
<li><a href="#ganttrunksrctestgroovyorgcodehausgantanttestsGant_Testjava" target="_top" rel="nofollow">gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/Gant_Test.java</a></li>
<li><a href="#ganttrunksrctestgroovyorgcodehausgantanttestsbuildgant" target="_top" rel="nofollow">gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/build.gant</a></li>
<li><a href="#ganttrunksrctestgroovyorgcodehausgantanttestsgantTestxml" target="_top" rel="nofollow">gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/gantTest.xml</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="ganttrunkreleaseNotestxt" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/releaseNotes.txt (10447 => 10448)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/releaseNotes.txt 2009-11-10 10:29:38 UTC (rev 10447)
+++ gant/trunk/releaseNotes.txt 2009-11-10 10:30:02 UTC (rev 10448)
</span><span class="lines">@@ -9,7 +9,10 @@
</span><span class="cx">
Altered the Gant Ant task so as to provide an inheritAll attribute. cf. GANT-110.
</span><span class="add">+Switched GantException from extending RuntimeException to extending org.apache.tools.ant.BuildException so
+as to allow better consistency with use of Gant from Ant. cf. GANT-111.
</span><span class="cx">
</span><span class="add">+
</span><span class="cx"> 1.8.1
-----
</span></pre></div>
<a id="ganttrunksrcmaingroovygantGantExceptiongroovy" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/src/main/groovy/gant/GantException.groovy (10447 => 10448)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/src/main/groovy/gant/GantException.groovy 2009-11-10 10:29:38 UTC (rev 10447)
+++ gant/trunk/src/main/groovy/gant/GantException.groovy 2009-11-10 10:30:02 UTC (rev 10448)
</span><span class="lines">@@ -14,12 +14,19 @@
</span><span class="cx">
package gant
</span><span class="add">+// Peter's original extended RuntimeException. GANT-111 introduced the problem that this cauises problems
+// for usage with Ant tasks -- where the exception really needs to be a descendent of
+// org.apache.tools.ant.BuildException. Making this change should not affect stand alone activity. Thanks
+// to Eric Van Dewoestine for providing this change.
+
+import org.apache.tools.ant.BuildException
+
</span><span class="cx"> /**
* Generic Gant exception.
*
* @author Peter Ledbrook
*/
</span><span class="rem">-class GantException extends RuntimeException {
</span><span class="add">+class GantException extends /*RuntimeException*/ BuildException {
</span><span class="cx"> public GantException ( ) { super( ) }
public GantException ( String msg ) { super ( msg ) }
public GantException ( Exception e ) { super ( e ) }
</span></pre></div>
<a id="ganttrunksrctestgroovyorgcodehausgantanttestsGant_Testjava" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/Gant_Test.java (10447 => 10448)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/Gant_Test.java 2009-11-10 10:29:38 UTC (rev 10447)
+++ gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/Gant_Test.java 2009-11-10 10:30:02 UTC (rev 10448)
</span><span class="lines">@@ -392,4 +392,13 @@
</span><span class="cx"> assertEquals ( " [echo] ${gant.test.inheritAll}" , output.get ( 15 ) ) ;
assertEquals ( " [echo] gantInheritAllWorks" , output.get ( 18 ) ) ;
}
</span><span class="add">+
+ // For dealing with GANT-111 -- thanks to Eric Van Dewoestine for providing this.
+
+ public void testGantTaskFaile ( ) {
+ final List<String> result = runAnt ( antFile.getPath ( ) , "gantTestFail" , 1 , true ) ;
+ assert result.size ( ) == 2 ;
+ assertEquals ( "\nBUILD FAILED\n: test fail message\n\n\n" , trimTimeFromSuccessfulBuild ( result.get ( 1 ) ) ) ;
+ }
+
</span><span class="cx"> }
</span></pre></div>
<a id="ganttrunksrctestgroovyorgcodehausgantanttestsbuildgant" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/build.gant (10447 => 10448)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/build.gant 2009-11-10 10:29:38 UTC (rev 10447)
+++ gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/build.gant 2009-11-10 10:30:02 UTC (rev 10448)
</span><span class="lines">@@ -65,4 +65,10 @@
</span><span class="cx"> echo ( message : '${gant.test.inheritAll}' )
}
</span><span class="add">+// For dealing with GANT-111 -- thanks to Eric Van Dewoestine for providing this.
+
+target ( testFail : '' ){
+ fail ( message : 'test fail message' )
+}
+
</span><span class="cx"> setDefaultTarget ( test )
</span></pre></div>
<a id="ganttrunksrctestgroovyorgcodehausgantanttestsgantTestxml" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/gantTest.xml (10447 => 10448)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/gantTest.xml 2009-11-10 10:29:38 UTC (rev 10447)
+++ gant/trunk/src/test/groovy/org/codehaus/gant/ant/tests/gantTest.xml 2009-11-10 10:30:02 UTC (rev 10448)
</span><span class="lines">@@ -71,4 +71,10 @@
</span><span class="cx"> <gant file="build.gant" target="gantInheritAll" inheritAll="true"/>
</target>
</span><span class="add">+ <!-- For GANT-111. Thanks to Eric Van Dewoestine for providing this. -->
+
+ <target name="gantTestFail" depends="-defineGantTask">
+ <gant file="build.gant" target="testFail"/>
+ </target>
+
</span><span class="cx"> </project>
</span>
</pre>
</div>
</div>
</body>
</html>
<hr />
<p>
To unsubscribe from this list please visit:
</p>
<p>
<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>
<p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26281243[gant-scm] [10447] gant/trunk/build.gradle: Add descriptions to the local install and uninstall tasks.2009-11-10T02:29:38Z2009-11-10T02:29:38Zrussel-9<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> [10447] gant/trunk/build.gradle: Add descriptions to the local install and uninstall tasks.</title>
</head>
<body>
<div id="msg">
<dl>
<dt>Revision</dt> <dd><a href="http://fisheye.codehaus.org/changelog/gant/?cs=10447" target="_top" rel="nofollow">10447</a></dd>
<dt>Author</dt> <dd>russel</dd>
<dt>Date</dt> <dd>2009-11-10 04:29:38 -0600 (Tue, 10 Nov 2009)</dd>
</dl>
<h3>Log Message</h3>
<pre>Add descriptions to the local install and uninstall tasks.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#ganttrunkbuildgradle" target="_top" rel="nofollow">gant/trunk/build.gradle</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="ganttrunkbuildgradle" target="_top"></a>
<div class="modfile"><h4>Modified: gant/trunk/build.gradle (10446 => 10447)</h4>
<pre class="diff">
<span class="info">--- gant/trunk/build.gradle 2009-11-09 17:42:07 UTC (rev 10446)
+++ gant/trunk/build.gradle 2009-11-10 10:29:38 UTC (rev 10447)
</span><span class="lines">@@ -166,8 +166,8 @@
</span><span class="cx"> dependencies { groovy ( 'org.codehaus.groovy:groovy-all:' + groovyVersion ) }
compileGroovy.doFirst { println ( '\n\tUsing Groovy version ' + groovyVersion + '\n' ) }
test.doFirst { groovyAntTaskTestVersionPropertyFile.write ( 'groovyAntTaskTestVersion = ' + groovyVersion ) }
</span><span class="rem">- task install ( dependsOn : 'assemble' ) << {
- def installDirectory = evaluate ( '"' + ( gant_installPath ?: '/usr/share/gant' ) + '"' )
</span><span class="add">+ def installDirectory = evaluate ( '"' + ( gant_installPath ?: '/usr/share/gant' ) + '"' )
+ task install ( dependsOn : 'assemble' , description : "Install Gant (compiled against Groovy ${groovyVersion}) to ${installDirectory}." ) << {
</span><span class="cx"> def installBinDirectory = installDirectory + '/bin'
def scriptsDirectory = '../scripts'
copy {
</span><span class="lines">@@ -185,7 +185,7 @@
</span><span class="cx"> from ( [ 'build/libs' , '../jarfiles' ] )
}
}
</span><span class="rem">- task uninstall << { ant.delete ( dir : evaluate ( /"${gant_installPath}"/ ) ) }
</span><span class="add">+ task uninstall ( description : "Delete ${installDirectory} so as to remove the Gant installation." ) << { ant.delete ( dir : installDirectory ) }
</span><span class="cx"> }
ciBuildTasks = [ ]
</span>
</pre>
</div>
</div>
</body>
</html>
<hr />
<p>
To unsubscribe from this list please visit:
</p>
<p>
<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>
<p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26281026Re: On static compilation of Groovy2009-11-10T02:11:16Z2009-11-10T02:11:16ZGuillaume Laforge-2On Mon, Nov 9, 2009 at 19:09, David Clark <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26281026&i=0" target="_top" rel="nofollow">davidclark@...</a>> wrote:
<br>> In your article you make the assertion, "due to performance reasons Groovy is
<br>> almost useless today for multi-core programming" without giving any reasons or
<br>> data to defend the assertion. I can't think of why this assertion should
<br>> hold. Of course Groovy is inappropriate for computation intensive code, but
<br>> this holds for any number of threads and any number of cores. Why would
<br>> properly parallelized Groovy code be inappropriate for code that engages in
<br>> lots of IO, which is the bulk of what business oriented code does?
<br><br>Indeed. Despite Groovy being slower than pure Java, the overhead is
<br>usually ridiculous compared to the time software waits for data to
<br>come up from the database. And optimizing the IO access is usually
<br>going to offer leaps in the scalability and/or performance of your
<br>code.
<br><br>> As for statically compiling Groovy code I'm all for it provided that 1) It's
<br>> entirely transparent for end users, 2) It does not increase the complexity of
<br>> the Groovy compiler thereby increasing bugs and slowing down development of
<br>> other features, and 3) It changes none of the semantics of current Groovy
<br>> code. I doubt those three things are possible, but I am willing to be proved
<br>> wrong.
<br><br>All this idea of a "static groovy" mode has been debated so many times
<br>in the past on the mailing-list that I'm lazy reiterating all the bad
<br>points about it.
<br>Just a one minute search brought me numerous threads on the topics, on
<br>the challenges and issues about this static groovy idea:
<br><a href="http://markmail.org/thread/ncv4uhcsd4qgtsni" target="_top" rel="nofollow">http://markmail.org/thread/ncv4uhcsd4qgtsni</a><br><a href="http://markmail.org/thread/rar6j5j47kl7yjlp" target="_top" rel="nofollow">http://markmail.org/thread/rar6j5j47kl7yjlp</a><br><a href="http://markmail.org/thread/wslb4sc75xsykbq3" target="_top" rel="nofollow">http://markmail.org/thread/wslb4sc75xsykbq3</a><br><a href="http://markmail.org/thread/ufo6ekbvlie3j3pm" target="_top" rel="nofollow">http://markmail.org/thread/ufo6ekbvlie3j3pm</a><br><a href="http://markmail.org/thread/hxfh5tpp6psyg6rg" target="_top" rel="nofollow">http://markmail.org/thread/hxfh5tpp6psyg6rg</a><br><a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br><a href="http://markmail.org/thread/p7hnerkarsyx3te7" target="_top" rel="nofollow">http://markmail.org/thread/p7hnerkarsyx3te7</a><br><a href="http://markmail.org/thread/g2a2gxahspj2iilt" target="_top" rel="nofollow">http://markmail.org/thread/g2a2gxahspj2iilt</a><br><a href="http://markmail.org/thread/nxt4e2oxfnf6m647" target="_top" rel="nofollow">http://markmail.org/thread/nxt4e2oxfnf6m647</a><br>And I'm sure there are even older threads on the topic.
<br><br>But to answer your points: 1) It won't be transparent in the sense
<br>that you would have to demarcate the code that would be made "static"
<br>(not a bad thing per se, though), but then avoid mixing static /
<br>non-static code, otherwise you wouldn't be able to really know what is
<br>or what is not statically compiled. 2) Of course it'll increase the
<br>complexity of the compiler. More advanced / complex features means
<br>more complexity to deal with, more bugs, a longer time to get it
<br>right, less resource / time to work on other features. And 3) it'd
<br>definitely change the semantics of current Groovy code, as for
<br>instance, the method resolution in a static mode is different from a
<br>dynamic mode. Groovy's multimethods wouldn't work, meaning that
<br>calling foo(a) wouldn't call the same method foo(Object) or foo(A) in
<br>static vs non-static mode. Groovy choses the method according to the
<br>runtime type, a static mode wouldn't.
<br>So this is all far from seamless, transparent. In the end, it somehow
<br>means maintaining two compilers in one.
<br><br>> Also, how many of the speed problems with dynamic dispatch will be alleviated
<br>> with the new invokedynamic that is supposed to start appearing in JVM's
<br>> sometime in the future?
<br><br>It's still early to really tell, as "invokedynamic" is still a work in
<br>progress. But hopefully, some significant gains will come from it,
<br>although it's still difficult to know what the real gains will be till
<br>there's a definitive working version available and testable.
<br>But I'd much rather see efforts improving "dynamic Groovy"
<br>(performance, features, etc), than abandonning this idea and turning
<br>Groovy into Java plus some syntaxic sugar only.
<br><br>> Also, if the objections to static compiling that I raised above cannot be met
<br>> there are alternatives to speeding up Groovy code that seem easier to
<br>> implement but would give big speedups to performance critical code. One would
<br>> be to allow embedding java or scala code like C/C++ compiles allow embedding
<br>> of ASM code. Granted it is already possible to mix and match Groovy, Java,
<br>> and Scala, so this doesn't provide anything that can't already be done, it
<br>> simply provides convenience to the programmer.
<br><br>The integration is pretty much seamless already.
<br>Adding a small Java class for a routine that needs to be speed up is so easy.
<br>Once you've got your project build using the groovyc compiler (Ant
<br>build, GMaven, Gradle, whatever), you usually don't have much work to
<br>do to joint-compile Groovy and Java together -- perhaps just a few
<br>lines to customize the javac call.
<br>The benefit also is it clearly demarcates what's statically-compiled
<br>(Java) and what's your dynamic code (Groovy).
<br><br>> [...]
<br><br>--
<br>Guillaume Laforge
<br>Groovy Project Manager
<br>Head of Groovy Development at SpringSource
<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26280721[gant-scm] [jira] Commented: (GANT-110) Add 'inheritAll' attribute to gant ant task.2009-11-10T01:43:55Z2009-11-10T01:43:55ZJIRA jira@codehaus.org<br> [ <a href="http://jira.codehaus.org/browse/GANT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197798#action_197798" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197798#action_197798</a> ]
<br><br>Russel Winder commented on GANT-110:
<br>------------------------------------
<br><br>I uploaded 1.9.0-SNAPSHOT distributions to the Gant Codehaus distributions store and artefacts to the Codehaus Maven snapshot repository last evening, so this should all now be testable without having to build Gant yourself. Hopefully it all works for people as expected.
<br><div class='shrinkable-quote'><br>> Add 'inheritAll' attribute to gant ant task.
<br>> --------------------------------------------
<br>>
<br>> Key: GANT-110
<br>> URL: <a href="http://jira.codehaus.org/browse/GANT-110" target="_top" rel="nofollow">http://jira.codehaus.org/browse/GANT-110</a><br>> Project: Gant
<br>> Issue Type: Improvement
<br>> Components: Ant Tasks
<br>> Affects Versions: 1.8.0
<br>> Reporter: Eric Van Dewoestine
<br>> Assignee: Russel Winder
<br>> Fix For: 1.9.0
<br>>
<br>> Attachments: gant_ant_inheritAll.diff
<br>>
<br>>
<br>> In ant both the <ant> and <antcall> tasks support an 'inheritAll' attribute which specifies whether or not the properties of the current project environment should be included in the sub-project created when invoking these tasks. The attached patch provides support for this feature to gant's ant task which, when inheritAll is enabled, allows the invoked gant script to utilize ant properties defined in the parent ant project.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>If you think it was sent incorrectly contact one of the administrators: <a href="http://jira.codehaus.org/secure/Administrators.jspa" target="_top" rel="nofollow">http://jira.codehaus.org/secure/Administrators.jspa</a><br>-
<br>For more information on JIRA, see: <a href="http://www.atlassian.com/software/jira" target="_top" rel="nofollow">http://www.atlassian.com/software/jira</a><br><br>
<br><br><hr/>
<br><p>
<br>To unsubscribe from this list please visit:
<br></p>
<br><p>
<br> <a href="<a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a>"><a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a></a>
<br><br><p>From forum: <a href="http://old.nabble.com/GANT----Scm-f33774.html" embed="fixTarget[33774]" target="_top" >GANT -- Scm</a></p>tag:old.nabble.com,2006:post-26280102Re: Mocking a method with > 1 parameter using closures not possible?2009-11-10T00:50:18Z2009-11-10T00:50:18ZGuillaume Laforge-2Yes.
<br><br>On Tue, Nov 10, 2009 at 09:47, Imner, Andreas <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=0" target="_top" rel="nofollow">Andreas.Imner@...</a>> wrote:
<div class='shrinkable-quote'><br>> Great thanks! I had tried that approach earlier but I must have missed something but now it works!
<br>>
<br>> Just to make things clear, the reason that mocking methods with 1 parameter works without defining any parameter in the closure, is that because of the implicit "it" parameter available in the closure body?
<br>>
<br>>
<br>>
<br>> Med vänlig hälsning
<br>> Andreas Imner
<br>> Systemutvecklare
<br>> KG Knutsson AB
<br>> Autokatalogen
<br>>
<br>> Tel: +46 8 92 34 37
<br>> Mobil: +46 70 606 34 37
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=1" target="_top" rel="nofollow">andreas.imner@...</a>
<br>>
<br>>
<br>>
<br>> -----Ursprungligt meddelande-----
<br>> Från: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=2" target="_top" rel="nofollow">glaforge@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=3" target="_top" rel="nofollow">glaforge@...</a>] För Guillaume Laforge
<br>> Skickat: den 10 november 2009 09:28
<br>> Till: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=4" target="_top" rel="nofollow">user@...</a>
<br>> Ämne: Re: [groovy-user] Mocking a method with > 1 parameter using closures not possible?
<br>>
<br>> You have to define your closure with as many arguments as needed.
<br>> So instead of { "test" }, you should use { String s1, String s3 -> "test" }
<br>>
<br>> On Tue, Nov 10, 2009 at 08:13, Imner, Andreas <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280102&i=5" target="_top" rel="nofollow">Andreas.Imner@...</a>> wrote:
<br>>>
<br>>> Hi.
<br>>>
<br>>> I am a Java developer just starting with Groovy and my goal is to use it for
<br>>> writing unit tests using Groovy
<br>>>
<br>>> My question: Why is it not possible to create a mock using closures for the
<br>>> following Java interface that has a method with 2 parameters? 1 Parameter
<br>>> works fine?
<br>>>
<br>>> public interface SomeInterface {
<br>>> public String getArticleStatus(String s1, String s2);
<br>>> }
<br>>>
<br>>>
<br>>> This is my Groovy test class ...
<br>>>
<br>>>
<br>>> class SomeTest extends GroovyTestCase {
<br>>>
<br>>> void testSomething() {
<br>>>
<br>>> def getArticleStatusResultHelperMethod = { "test"}
<br>>> def myMock = [getArticleStatus:getArticleStatusResultHelperMethod]
<br>>> as SomeInterface
<br>>>
<br>>> assertEquals (myMock.getArticleStatus(), "test")
<br>>> }
<br>>>
<br>>> }
<br>>>
<br>>> This is my output...
<br>>>
<br>>> [junit] Testcase: testSomeThing took 0,031 sec
<br>>> [junit] Caused an ERROR
<br>>> [junit] No signature of method: $Proxy0.getArticleStatus() is applicable
<br>>> for
<br>>> argument types: () values: []
<br>>> [junit] groovy.lang.MissingMethodException: No signature of method:
<br>>> $Proxy0.
<br>>> getArticleStatus() is applicable for argument types: () values: []
<br>>> [junit] at
<br>>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(Scri
<br>>> ptBytecodeAdapter.java:54)
<br>>> [junit] at
<br>>> org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(P
<br>>> ojoMetaClassSite.java:46)
<br>>> [junit] at
<br>>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal
<br>>> l(CallSiteArray.java:40)
<br>>> [junit] at
<br>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>>> stractCallSite.java:117)
<br>>> [junit] at
<br>>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>>> stractCallSite.java:121)
<br>>> [junit] at
<br>>> se.kgk.webshop.integration.erp.SomeTest.testSomeThing(SomeTes
<br>>> t.groovy:12)
<br>>> [junit]
<br>>>
<br>>>
<br>>> If I change the interface to...
<br>>>
<br>>> public interface SomeInterface {
<br>>> public String getArticleStatus(String s1);
<br>>> }
<br>>>
<br>>> The result is…
<br>>>
<br>>> [junit] Running se.kgk.webshop.integration.erp.SomeTest
<br>>> [junit] Testsuite: se.kgk.webshop.integration.erp.SomeTest
<br>>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>>> [junit]
<br>>> [junit] Testcase: testSomeThing took 0,11 sec
<br>>>
<br>>> /Andreas
<br>>>
<br>>
<br>>
<br>>
<br>> --
<br>> Guillaume Laforge
<br>> Groovy Project Manager
<br>> Head of Groovy Development at SpringSource
<br>> <a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
</div><br><br><br>--
<br>Guillaume Laforge
<br>Groovy Project Manager
<br>Head of Groovy Development at SpringSource
<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26280069SV: Mocking a method with > 1 parameter using closures not possible?2009-11-10T00:47:46Z2009-11-10T00:47:46ZImner, AndreasGreat thanks! I had tried that approach earlier but I must have missed something but now it works!
<br><br>Just to make things clear, the reason that mocking methods with 1 parameter works without defining any parameter in the closure, is that because of the implicit "it" parameter available in the closure body?
<br><br><br><br>Med vänlig hälsning
<br>Andreas Imner
<br>Systemutvecklare
<br>KG Knutsson AB
<br>Autokatalogen
<br><br>Tel: +46 8 92 34 37
<br>Mobil: +46 70 606 34 37
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280069&i=0" target="_top" rel="nofollow">andreas.imner@...</a>
<br><br><br><br>-----Ursprungligt meddelande-----
<br>Från: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280069&i=1" target="_top" rel="nofollow">glaforge@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280069&i=2" target="_top" rel="nofollow">glaforge@...</a>] För Guillaume Laforge
<br>Skickat: den 10 november 2009 09:28
<br>Till: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280069&i=3" target="_top" rel="nofollow">user@...</a>
<br>Ämne: Re: [groovy-user] Mocking a method with > 1 parameter using closures not possible?
<br><br>You have to define your closure with as many arguments as needed.
<br>So instead of { "test" }, you should use { String s1, String s3 -> "test" }
<br><br>On Tue, Nov 10, 2009 at 08:13, Imner, Andreas <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26280069&i=4" target="_top" rel="nofollow">Andreas.Imner@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> Hi.
<br>>
<br>> I am a Java developer just starting with Groovy and my goal is to use it for
<br>> writing unit tests using Groovy
<br>>
<br>> My question: Why is it not possible to create a mock using closures for the
<br>> following Java interface that has a method with 2 parameters? 1 Parameter
<br>> works fine?
<br>>
<br>> public interface SomeInterface {
<br>> public String getArticleStatus(String s1, String s2);
<br>> }
<br>>
<br>>
<br>> This is my Groovy test class ...
<br>>
<br>>
<br>> class SomeTest extends GroovyTestCase {
<br>>
<br>> void testSomething() {
<br>>
<br>> def getArticleStatusResultHelperMethod = { "test"}
<br>> def myMock = [getArticleStatus:getArticleStatusResultHelperMethod]
<br>> as SomeInterface
<br>>
<br>> assertEquals (myMock.getArticleStatus(), "test")
<br>> }
<br>>
<br>> }
<br>>
<br>> This is my output...
<br>>
<br>> [junit] Testcase: testSomeThing took 0,031 sec
<br>> [junit] Caused an ERROR
<br>> [junit] No signature of method: $Proxy0.getArticleStatus() is applicable
<br>> for
<br>> argument types: () values: []
<br>> [junit] groovy.lang.MissingMethodException: No signature of method:
<br>> $Proxy0.
<br>> getArticleStatus() is applicable for argument types: () values: []
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(Scri
<br>> ptBytecodeAdapter.java:54)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(P
<br>> ojoMetaClassSite.java:46)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal
<br>> l(CallSiteArray.java:40)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>> stractCallSite.java:117)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>> stractCallSite.java:121)
<br>> [junit] at
<br>> se.kgk.webshop.integration.erp.SomeTest.testSomeThing(SomeTes
<br>> t.groovy:12)
<br>> [junit]
<br>>
<br>>
<br>> If I change the interface to...
<br>>
<br>> public interface SomeInterface {
<br>> public String getArticleStatus(String s1);
<br>> }
<br>>
<br>> The result is…
<br>>
<br>> [junit] Running se.kgk.webshop.integration.erp.SomeTest
<br>> [junit] Testsuite: se.kgk.webshop.integration.erp.SomeTest
<br>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>> [junit]
<br>> [junit] Testcase: testSomeThing took 0,11 sec
<br>>
<br>> /Andreas
<br>>
</div><br><br><br>--
<br>Guillaume Laforge
<br>Groovy Project Manager
<br>Head of Groovy Development at SpringSource
<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26279868Re: Mocking a method with > 1 parameter using closures not possible?2009-11-10T00:28:01Z2009-11-10T00:28:01ZGuillaume Laforge-2You have to define your closure with as many arguments as needed.
<br>So instead of { "test" }, you should use { String s1, String s3 -> "test" }
<br><br>On Tue, Nov 10, 2009 at 08:13, Imner, Andreas <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26279868&i=0" target="_top" rel="nofollow">Andreas.Imner@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> Hi.
<br>>
<br>> I am a Java developer just starting with Groovy and my goal is to use it for
<br>> writing unit tests using Groovy
<br>>
<br>> My question: Why is it not possible to create a mock using closures for the
<br>> following Java interface that has a method with 2 parameters? 1 Parameter
<br>> works fine?
<br>>
<br>> public interface SomeInterface {
<br>> public String getArticleStatus(String s1, String s2);
<br>> }
<br>>
<br>>
<br>> This is my Groovy test class ...
<br>>
<br>>
<br>> class SomeTest extends GroovyTestCase {
<br>>
<br>> void testSomething() {
<br>>
<br>> def getArticleStatusResultHelperMethod = { "test"}
<br>> def myMock = [getArticleStatus:getArticleStatusResultHelperMethod]
<br>> as SomeInterface
<br>>
<br>> assertEquals (myMock.getArticleStatus(), "test")
<br>> }
<br>>
<br>> }
<br>>
<br>> This is my output...
<br>>
<br>> [junit] Testcase: testSomeThing took 0,031 sec
<br>> [junit] Caused an ERROR
<br>> [junit] No signature of method: $Proxy0.getArticleStatus() is applicable
<br>> for
<br>> argument types: () values: []
<br>> [junit] groovy.lang.MissingMethodException: No signature of method:
<br>> $Proxy0.
<br>> getArticleStatus() is applicable for argument types: () values: []
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(Scri
<br>> ptBytecodeAdapter.java:54)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(P
<br>> ojoMetaClassSite.java:46)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal
<br>> l(CallSiteArray.java:40)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>> stractCallSite.java:117)
<br>> [junit] at
<br>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab
<br>> stractCallSite.java:121)
<br>> [junit] at
<br>> se.kgk.webshop.integration.erp.SomeTest.testSomeThing(SomeTes
<br>> t.groovy:12)
<br>> [junit]
<br>>
<br>>
<br>> If I change the interface to...
<br>>
<br>> public interface SomeInterface {
<br>> public String getArticleStatus(String s1);
<br>> }
<br>>
<br>> The result is…
<br>>
<br>> [junit] Running se.kgk.webshop.integration.erp.SomeTest
<br>> [junit] Testsuite: se.kgk.webshop.integration.erp.SomeTest
<br>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec
<br>> [junit]
<br>> [junit] Testcase: testSomeThing took 0,11 sec
<br>>
<br>> /Andreas
<br>>
</div><br><br><br>--
<br>Guillaume Laforge
<br>Groovy Project Manager
<br>Head of Groovy Development at SpringSource
<br><a href="http://www.springsource.com/g2one" target="_top" rel="nofollow">http://www.springsource.com/g2one</a><br><br>---------------------------------------------------------------------
<br>To unsubscribe from this list, please visit:
<br><br> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br><br><br><p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26279711Re: Creating a List2009-11-10T00:11:19Z2009-11-10T00:11:19ZdouggiefoxHi
<br><br>Nice one.
<br><br>Best
<br><br>DF
<br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Tim Yates wrote:</div>
<div class="quote-message shrinkable-quote">I'd use JsonSlurper (part of json-lib):
<br><br>@Grab('net.sf.json-lib:json-lib:2.3:jdk15')
<br>import net.sf.json.groovy.JsonSlurper
<br><br>JsonSlurper slurper = new JsonSlurper()
<br>def res = slurper.parseText( "[{\"name\":\"A new
<br>member\",\"age\":21,\"cover\":\"Single\",\"londonUpgrade\":0},{\"name\":\"A
<br>new member\",\"age\":21,\"cover\":\"Single\",\"excess\":\"\"}]" )
<br>println res
<br><br>Tim
<br><br>On Mon, Nov 9, 2009 at 9:55 AM, douggiefox <paul@javabytes.co.uk> wrote:
<br><br>>
<br>> Hi
<br>>
<br>> I have a string that's come from a HTML page and is encoded like this:
<br>>
<br>> "[{\"name\":\"A new
<br>> member\",\"age\":21,\"cover\":\"Single\",\"londonUpgrade\":0},{\"name\":\"A
<br>> new member\",\"age\":21,\"cover\":\"Single\",\"excess\":\"\"}]"
<br>>
<br>> Is there a simple way I can convert this to a List?
<br>>
<br>> Best
<br>>
<br>> DF
<br>> --
<br>> View this message in context:
<br>> <a href="http://old.nabble.com/Creating-a-List-tp26263681p26263681.html" target="_top" rel="nofollow">http://old.nabble.com/Creating-a-List-tp26263681p26263681.html</a><br>> Sent from the groovy - user mailing list archive at Nabble.com.
<br>>
<br>>
<br>> ---------------------------------------------------------------------
<br>> To unsubscribe from this list, please visit:
<br>>
<br>> <a href="http://xircles.codehaus.org/manage_email" target="_top" rel="nofollow">http://xircles.codehaus.org/manage_email</a><br>>
<br>>
<br>>
</div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>tag:old.nabble.com,2006:post-26279222Mocking a method with > 1 parameter using closures not possible?2009-11-09T23:13:18Z2009-11-09T23:13:18ZImner, Andreas<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
</head>
<body>
<font face="Arial, sans-serif" size="3">
<div> </div>
<div><font size="2">Hi.</font></div>
<div><font size="2"> </font></div>
<div><font size="2">I am a Java developer just starting with Groovy and my goal is to use it for writing unit tests using Groovy</font></div>
<div><font size="2"> </font></div>
<div><font size="2">My question: Why is it not possible to create a mock using closures for the following Java interface that has a method with 2 parameters? 1 Parameter works fine?</font></div>
<div><font size="2"> </font></div>
<div><font size="2">public interface SomeInterface {</font></div>
<div><font size="2"> public String getArticleStatus(String s1, String s2);</font></div>
<div><font size="2">}</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> </font></div>
<div><font size="2">This is my Groovy test class ...</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> </font></div>
<div><font size="2">class SomeTest extends GroovyTestCase {</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> void testSomething() {</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> def getArticleStatusResultHelperMethod = { "test"}</font></div>
<div><font size="2"> def myMock = [getArticleStatus:getArticleStatusResultHelperMethod] as SomeInterface</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> assertEquals (myMock.getArticleStatus(), "test")</font></div>
<div><font size="2"> }</font></div>
<div><font size="2"> </font></div>
<div><font size="2">}</font></div>
<div><font size="2"> </font></div>
<div><font size="2">This is my output...</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> [junit] Testcase: testSomeThing took 0,031 sec</font></div>
<div><font size="2"> [junit] Caused an ERROR</font></div>
<div><font size="2"> [junit] No signature of method: $Proxy0.getArticleStatus() is applicable for</font></div>
<div><font size="2"> argument types: () values: []</font></div>
<div><font size="2"> [junit] groovy.lang.MissingMethodException: No signature of method: $Proxy0.</font></div>
<div><font size="2">getArticleStatus() is applicable for argument types: () values: []</font></div>
<div><font size="2"> [junit] at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(Scri</font></div>
<div><font size="2">ptBytecodeAdapter.java:54)</font></div>
<div><font size="2"> [junit] at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(P</font></div>
<div><font size="2">ojoMetaClassSite.java:46)</font></div>
<div><font size="2"> [junit] at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal</font></div>
<div><font size="2">l(CallSiteArray.java:40)</font></div>
<div><font size="2"> [junit] at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab</font></div>
<div><font size="2">stractCallSite.java:117)</font></div>
<div><font size="2"> [junit] at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(Ab</font></div>
<div><font size="2">stractCallSite.java:121)</font></div>
<div><font size="2"> [junit] at se.kgk.webshop.integration.erp.SomeTest.testSomeThing(SomeTes</font></div>
<div><font size="2">t.groovy:12)</font></div>
<div><font size="2"> [junit]</font></div>
<div><font size="2"> </font></div>
<div><font size="2"> </font></div>
<div><font size="2">If I change the interface to...</font></div>
<div><font size="2"> </font></div>
<div><font size="2">public interface SomeInterface {</font></div>
<div><font size="2"> public String getArticleStatus(String s1);</font></div>
<div><font size="2">}</font></div>
<div><font size="2"> </font></div>
<div><font size="2">The result is…</font></div>
<div><font size="2"> </font></div>
<div><font size="2">[junit] Running se.kgk.webshop.integration.erp.SomeTest</font></div>
<div><font size="2">[junit] Testsuite: se.kgk.webshop.integration.erp.SomeTest</font></div>
<div><font size="2">[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec</font></div>
<div><font size="2">[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,266 sec</font></div>
<div><font size="2">[junit]</font></div>
<div><font size="2">[junit] Testcase: testSomeThing took 0,11 sec</font></div>
<div><font size="2"> </font></div>
<div><font size="2">/Andreas</font></div>
<div><font size="2"> </font></div>
</font>
</body>
</html>
<p>From forum: <a href="http://old.nabble.com/groovy---user-f11867.html" embed="fixTarget[11867]" target="_top" >groovy - user</a></p>