[groovy-user] Trying to get HTTPClient to work - can't resolve dependencies

[Bill Wright]

Hi all,

I'm trying to get the simplest example working from this page:

http://groovy.codehaus.org/modules/http-builder/doc/get.html

I'm not using Maven to build anything and just want to throw together a
test. I tried using Grape and it spewed errors all over the screen like
this:

:::: ERRORS
Server access Error: Connection refused
url=http://repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0/http-builder-0.5.0.pom
...

So I just typed in my program like this:

-----------------
#!/usr/bin/env groovy

import groovyx.net.http.HTTPBuilder
import groovy.util.slurpersupport.GPathResult
import static groovyx.net.http.ContentType.URLENC

def http = new HTTPBuilder('http://www.google.com')

def html = http.get( path : '/search', query : [q:'Groovy'] )
--------------

When I tried to run it I got this error first:

[tendril@tendril-ff noc_scripts]$ testRest3
Caught: java.lang.NoClassDefFoundError: org/apache/http/HttpRequest
at testRest3.class$(testRest3)
at testRest3.$get$$class$groovyx$net$http$HTTPBuilder(testRest3)
at testRest3.run(testRest3:7)


So then I went and got the httpcore-4.0.1.jar and put it in my
$GROOVY_HOME/lib dir. Now I get this error:

[tendril@tendril-ff noc_scripts]$ testRest3
Caught: java.lang.NoClassDefFoundError: net/sf/json/JSONObject
at testRest3.run(testRest3:7)

What a royal pain in the butt. Is there anyway to find out the dependencies
for HTTPBuilder? On the web page it just says:

JAR dependencies can be found in the packaged distributions linked from the
download page.

What linked packages? On the download page there is maven config code, some
Grape stuff that didn't work for me and a link to the download zip. No
dependencies are explicitly listed here. Is adding them manually a futile
process? Are there so many that they can't be listed? How should I proceed?
Figure out what is wrong with Grape?

Thanks for any pointers on how to proceed.

Bill
--
View this message in context: http://old.nabble.com/Trying-to-get-HTTPClient-to-work---can%27t-resolve-dependencies-tp28466017p28466017.html
Sent from the groovy - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


--
You received this message because you are subscribed to the Google Groups "Groovy Users" group.
To post to this group, send email to groov...@googlegroups.com.
To unsubscribe from this group, send email to groovy-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/groovy-user?hl=en.

[Tom Nichols]

Hi Bill,

First off, I tried that Grape URL to repository.codehaus.org and it
worked for me. Are you behind a proxy? This @Grab annotation worked
for me:
@Grab(group='org.codehaus.groovy.modules.http-builder',
module='http-builder', version='0.5.0')

Second: I guess the download instructions are a little vague. The
download page has a link to the Maven repository, to which I've
published an tar.gz and .zip assembly that includes all dependency
JARs.
http://repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0/http-builder-0.5.0-all.tar.gz
or http://repository.codehaus.org/org/codehaus/groovy/modules/http-builder/http-builder/0.5.0/http-builder-0.5.0-all.zip

Hope this works out for you.

-Tom

[Bill Wright]

Hi Tom,

First, thanks so much for the very informative reply. I appreciate it.

I was trying this from one of our Linux server machines that is in our NOC
and behind a firewall (and presumably a proxy?) and the Grape get did not
work. Trying it directly from my Mac worked fine. I'm not sure what do after
the Grape get, though, as it puts a bunch of jars in the maven repository on
my machine (but I'm not using Maven to build anything). Not sure how to use
Grape, really. I couldn't embed it, either, since it has to annotate a
method, right? I could make a method in my script, of course, but I
currently don't explicitly have one.

I'm mainly running groovy scripts and jars as needed by adding them to
either the groovy home/lib dir or another directory that I have in the
classpath. So, getting all the dependent jars that you identified was a
great help. Thanks.

Anyway, I'm off and running now. Much appreciated!

Bill

View this message in context: http://old.nabble.com/Trying-to-get-HTTPClient-to-work---can%27t-resolve-dependencies-tp28466017p28473408.html

Sent from the groovy - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Thom Nichols]

On Thu, May 6, 2010 at 9:12 AM, Bill Wright <bi...@wwwright.com> wrote:

I was trying this from one of our Linux server machines that is in our NOC
and behind a firewall (and presumably a proxy?) and the Grape get did not
work.

Grape is actually a Groovy wrapper around the Ivy package manager (which is sort of an alternative to Maven.)  I think Ivy will respect your Java proxy system properties (i.e. -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3122) then it should work from behind your proxy.  Ivy just uses HTTP, so presumably if you can access repository.codehaus.org from your browser, you should be able to use Grape.  (Look at your browser's proxy settings :)
 

Trying it directly from my Mac worked fine. I'm not sure what do after
the Grape get, though, as it puts a bunch of jars in the maven repository on
my machine (but I'm not using Maven to build anything). Not sure how to use
Grape, really.

The @Grab annotation downloads the dependencies (if they haven't been downloaded once already) and more importantly puts them on the classpath.  This is particularly handy for scripts so that you don't need to have a long -cp command line to invoke the Java runtime with all of the JARs on your classpath.
 

I couldn't embed it, either, since it has to annotate a
method, right? I could make a method in my script, of course, but I
currently don't explicitly have one.

As of Groovy 1.7 I believe you can put an annotation on just about anything, so the @Grab annotation can come at the top of your script even before your import statements -- which makes the most sense for a Grab annotation if you ask me.  If you're using Groovy 1.6, you can just add a dummy method near the top of your script like:

@Grab(.....)
def grapeDummy() {}
 

I'm mainly running groovy scripts and jars as needed by adding them to
either the groovy home/lib dir or another directory that I have in the
classpath. So, getting all the dependent jars that you identified was a
great help. Thanks.

Yup, that's certainly another option.   You just have to be careful about putting _too_much_ there since eventually you'll end up with two libraries in ~/.groovy/lib that are incompatible (e.g. depend on different versions of the same library X).  Also the Grab annotation allow you to pass the script to any other user who can run the script without making them manually download anything dependency JARs first.

-Tom

[charlie]

I couldn't get @Grab to ever actually put the lib on my classpath.  I see that it downloads the libs to ~/.groovy/grapes , but when running `groovy foo.groovy` from the CL, it never had visibility to the libs that I @Grab'ed .

On Thu, May 6, 2010 at 10:14 AM, Thom Nichols <tmni...@gmail.com> wrote:

On Thu, May 6, 2010 at 9:12 AM, Bill Wright <bi...@wwwright.com> wrote:

I was trying this from one of our Linux server machines that is in our NOC
and behind a firewall (and presumably a proxy?) and the Grape get did not
work.

Grape is actually a Groovy wrapper around the Ivy package manager (which is sort of an alternative to Maven.)  I think Ivy will respect your Java proxy system properties (i.e. -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3122) then it should work from behind your proxy.  Ivy just uses HTTP, so presumably if you can access repository.codehaus.org from your browser, you should be able to use Grape.  (Look at your browser's proxy settings :)
 

Trying it directly from my Mac worked fine. I'm not sure what do after
the Grape get, though, as it puts a bunch of jars in the maven repository on
my machine (but I'm not using Maven to build anything). Not sure how to use
Grape, really.

The @Grab annotation downloads the dependencies (if they haven't been downloaded once already) and more importantly puts them on the classpath.  This is particularly handy for scripts so that you don't need to have a long -cp command line to invoke the Java runtime with all of the JARs on your classpath.
 

I couldn't embed it, either, since it has to annotate a
method, right? I could make a method in my script, of course, but I
currently don't explicitly have one.

As of Groovy 1.7 I believe you can put an annotation on just about anything, so the @Grab annotation can come at the top of your script even before your import statements -- which makes the most sense for a Grab annotation if you ask me.  If you're using Groovy 1.6, you can just add a dummy method near the top of your script like:

@Grab(.....)
def grapeDummy() {}
 

I'm mainly running groovy scripts and jars as needed by adding them to
either the groovy home/lib dir or another directory that I have in the
classpath. So, getting all the dependent jars that you identified was a
great help. Thanks.

Yup, that's certainly another option.   You just have to be careful about putting _too_much_ there since eventually you'll end up with two libraries in ~/.groovy/lib that are incompatible (e.g. depend on different versions of the same library X).  Also the Grab annotation allow you to pass the script to any other user who can run the script without making them manually download anything dependency JARs first.

-Tom

--

<charlie/>

[Thom Nichols]

Really?  So if that @Grab script is _in_ foo.groovy, it downloads the JARs but then you get a ClassNotFoundException as soon as you try to use something from the JAR that you just grabbed?  That's odd...  What happens if you run the same script in GroovyConsole?

[charlie]

I'm  taking the example from http://groovy.codehaus.org/HTTP+Builder , putting it into a foo.groovy script. 

Both running from command line and in GroovyConsole I get:


unable to resolve class groovyx.net.http.ContentType
 at line: 4, column: 1
...

including the apache httpclient imports.


Using groovy 1.6.3, and JVM 1.6.0_15.  I'll try upgrading to 1.7 see if it helps.

[charlie]

The latest release of groovy doesn't have this problem, it works both in console and the shell.

I'm using ubuntu, which has 1.6.3 in it's repo's.  Maybe we need to get them to upgrade to a newer release :).

Cheers!  I'm glad I can use grapes now :).

[Chris Banford]

Hi Groovy gurus,

Can someone who's a bit better with Windows (XP) command line take a
look at this and possibly give a hint as to how I can get this working?
I've dug, and dug on various web pages, and tried a day and a half's
worth of variations, to no avail (can get it to work fine from the
command prompt in windows...

def proc = 'cmd "C:\\Program Files\\FileZilla Server" dir && "FileZilla
server.exe" /reload-config'.execute()

Any pointers/help would be hugely appreciated :-)

Cheers,
-Chris

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Denis Zhdanov]

Try to define '/c' key, i.e. 'cmd /c ...'

On Thu, May 6, 2010 at 8:53 PM, Chris Banford <d...@bsoft.ch> wrote:

Hi Groovy gurus,

Can someone who's a bit better with Windows (XP) command line take a look at this and possibly give a hint as to how I can get this working? I've dug, and dug on various web pages, and tried a day and a half's worth of variations, to no avail (can get it to work fine from the command prompt in windows...

def proc = 'cmd "C:\\Program Files\\FileZilla Server" dir && "FileZilla server.exe" /reload-config'.execute()

Any pointers/help would be hugely appreciated :-)

Cheers,
-Chris




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--

http://denis-zhdanov.blogspot.com

[Chris Banford]

Hi Denis,

Thanks for that (I stumbled across it just as your mail came in - typical! :-) )

It's almost working...

If I run this directly from a Groovy script, all is happy and FileZilla Server is reloading its xml settings file:
println 'cmd /c "C:\\Program Files\\FileZilla Server\\FileZilla server.exe" /reload-config'.execute()

but if I run the exact same line in a Groovy class, it's not working.
I'm guessing I'm missing something basic again [sigh]

Any thoughts?

Cheers,
-Chris

[Chris Banford]

Hi again,

Some more investigation leads to me being very puzzled. 1) works. 2) doesn't work (this is all running in the top level groovy script)

// 1) Works here still.
//println 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla Server.exe" /reload-config'.execute().text

def response = wtsClient.createDesignPackage( newPackName );

// 2) Doesn't work here anymore ???
println 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla Server.exe" /reload-config'.execute().text

Even if I put this .execute() line as the first line in the called method [wtsClient.createDesignPackage] it still fails.

Am at a complete loss.

-Chris

[Denis Zhdanov]

Hi Chris,

I'm afraid the problem is not clear - you said that 1) works but 2) doesn't work but what's the difference between 1) and 2)? As far as I see both lines are the same, so, I assume that the change is if they are located before or after 'wtsClient.createDesignPackage()' call, right?

Another question is the meaning of 'doesn't work' - how do you check whether the call works or not? Is it the case that current thread just hangs during 'wtsClient.createDesignPackage()' processing and control flow doesn't reach the second instruction?

I.e. the main idea is to try to work out minimal but complete standalone example that illustrates the problem and post it here because it's rather hard to understand what exactly happens at your environment.

Regards, Denis

[Chris Banford]

Hi Dennis,

Yes, it sounds like I'm totally clueless on this (and that's probably partially true :-) ).

I'm afraid the problem is not clear - you said that 1) works but 2) doesn't work but what's the difference between 1) and 2)? As far as I see both lines are the same, so, I assume that the change is if they are located before or after 'wtsClient.createDesignPackage()' call, right?

That's what is making this so hard to figure out -- why are the same calls working/failing in these weird and wonderful ways? Moving the call from the script (directly above the class method call) to the first line inside that method, caused it to stop working.

Another question is the meaning of 'doesn't work' - how do you check whether the call works or not? Is it the case that current thread just hangs during 'wtsClient.createDesignPackage()' processing and control flow doesn't reach the second instruction?

After spending another solid 12 hours battling with this, it seems that it's some sort of issue between the way Java (groovy) is calling the windows command line and the way that is then being handled by the FileZilla Server app.

The command line calls all work perfectly when run directly in windows

I was also using MS' Procmon.exe to try and see where things are failing, but the calls and return codes from my groovy code seemed to be correct.

I.e. the main idea is to try to work out minimal but complete standalone example that illustrates the problem and post it here because it's rather hard to understand what exactly happens at your environment.

Yes, I understand -- in the beginning I thought I was just making a simple beginners mistake (hence posting with too little pertinent info), but now not so sure.

Although I haven't figured out why/where it's getting confused, I've managed to get it working by doing the following:

1. At the start of my main groovy script, run an execute() that stops the FileZilla Server
   // shut down FileZilla Server
   def proc = 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla Server.exe" /stop'.execute()
   proc.waitFor()
   
   
2. Run all of my existing code (simple stuff really), that includes adding a new FTP user account to the FileZilla Server.xml
   // Various simple groovy code running here...
   
   
3. at the end of the groovy main script, re-start the FileZilla Server and then reload its settings file (two sep execute() calls).
   // Total hack. But seems to work...
   proc = 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla Server.exe" /start'.execute()
   proc.waitFor()
   

1. 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla Server.exe" /reload-config'.execute()

1. 
   
   

Ideally, I wanted to handle all of this FileZilla Server stuff in a self-contained FTP class, but as soon as I move these calls elsewhere, they don't work. I've tried dozens of combinations of things, from ant to running the calls in a sep thread, but to no avail.


Strange, and I'm sure it's something that I'm not grokking properly, but have it working finally :-) . I have a strong feeling that doing the same thing on a Linux box would have been a *lot* more straight-forward (the infinite joys of Windows!!!).

Many thanks for taking the time to reply -- greatly appreciated!

Cheers,
-Chris

[Paul King]

Again, not sure what is happening without more details but ...
if the FileZilla server outputs much to stdout or stderr then
you need to consume that output to avoid OS-level hanging.
See the consumeProcessXXX methods for details.

Cheers, Paul.

On 7/05/2010 6:44 PM, Chris Banford wrote:
> Hi Dennis,
>
> Yes, it sounds like I'm totally clueless on this (and that's probably
> partially true :-) ).
>
>> I'm afraid the problem is not clear - you said that 1) works but 2)
>> doesn't work but what's the difference between 1) and 2)? As far as I
>> see both lines are the same, so, I assume that the change is if they

>> are located before or after /'wtsClient.createDesignPackage()'/ call,

>> right?
>
> That's what is making this so hard to figure out -- why are the same
> calls working/failing in these weird and wonderful ways? Moving the call
> from the script (directly above the class method call) to the first line
> inside that method, caused it to stop working.
>

>> Another question is the meaning of /'doesn't work'/ - how do you check

>> whether the call works or not? Is it the case that current thread just

>> hangs during /'wtsClient.createDesignPackage()' /processing and

>> control flow doesn't reach the second instruction?
>
> After spending another solid 12 hours battling with this, it seems that
> it's some sort of issue between the way Java (groovy) is calling the
> windows command line and the way that is then being handled by the
> FileZilla Server app.
>
> The command line calls all work perfectly when run directly in windows
>
> I was also using MS' Procmon.exe to try and see where things are
> failing, but the calls and return codes from my groovy code seemed to be
> correct.
>
>> I.e. the main idea is to try to work out minimal but complete
>> standalone example that illustrates the problem and post it here
>> because it's rather hard to understand what exactly happens at your
>> environment.
>
> Yes, I understand -- in the beginning I thought I was just making a
> simple beginners mistake (hence posting with too little pertinent info),
> but now not so sure.
>
> Although I haven't figured out why/where it's getting confused, I've
> managed to get it working by doing the following:
>

> 1. At the start of my main groovy script, run an execute() that stops

> the FileZilla Server
> // shut down FileZilla Server
> def proc = 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla
> Server.exe" /stop'.execute()
> proc.waitFor()
>

> 2. Run all of my existing code (simple stuff really), that includes

> adding a new FTP user account to the FileZilla Server.xml
> // Various simple groovy code running here...
>

> 3. at the end of the groovy main script, re-start the FileZilla

[Chris Banford]

Thanks Paul -- that sounds like a possible cause. Will look into it...
-Chris

>
> Again, not sure what is happening without more details but ...
> if the FileZilla server outputs much to stdout or stderr then
> you need to consume that output to avoid OS-level hanging.
> See the consumeProcessXXX methods for details.
>
> Cheers, Paul.
>

[Chris Banford]

Hi Paul,

> Again, not sure what is happening without more details but ...
> if the FileZilla server outputs much to stdout or stderr then
> you need to consume that output to avoid OS-level hanging.
> See the consumeProcessXXX methods for details.

Have tried the above, and either I'm still getting it wrong or it's just
not working in this case. Here's my bit of code (actually only really
want to reload the settings xml file, but have been using Stop + Start
as it makes it work in the calling script...)

I'm just using a groovy script that is calling a method of a class that
adds a new FTP User account to the FileZilla Server.xml file, and then
calls the below restartServer().

/**
* Restart the FTP Server
*/
public boolean restartServer() {

// Stop the FTP Server
println " -> Stopping FileZilla Server (FTP)"

def proc = 'cmd /c "c:\\Program Files\\FileZilla
Server\\FileZilla Server.exe" /stop'.execute()

proc.consumeProcessOutput()
proc.waitForOrKill( 2000 )

// Restart the FTP server.
println " -> Reloading FileZilla Server's 'settings' xml
file (FTP)"

proc = 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla
Server.exe" /start'.execute()

proc.consumeProcessOutput()
proc.waitForOrKill( 10000 )

// Reload the settings xml file.
println " -> Starting FileZilla Server (FTP)"

proc = 'cmd /c "c:\\Program Files\\FileZilla Server\\FileZilla

Server.exe" /reload-config'.execute()
proc.consumeProcessOutput()
proc.waitForOrKill( 2000 )

}

Anything obvious that I'm doing wrong here? If I move these commands to
the calling script (putting the Stop at the top and the Start & Reload
at the bottom) then it works. Feels like it's some sort of timing issue...

Cheers,
-Chris







---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


--

[Ray Tayek]

At 01:11 PM 5/7/2010, you wrote:
...

>I'm just using a groovy script that is calling a method of a class
>that adds a new FTP User account to the FileZilla Server.xml file,
>and then calls the below restartServer().

>...

> def proc = 'cmd /c "c:\\Program Files\\FileZilla
> Server\\FileZilla Server.exe" /stop'.execute()

> ...

>
>Anything obvious that I'm doing wrong here? If I move these commands
>to the calling script (putting the Stop at the top and the Start &
>Reload at the bottom) then it works. Feels like it's some sort of
>timing issue...

pm4ji, try using start: cmd /c start "c:\\Program Files\\FileZilla
Server\\FileZilla Server.exe" /stop

this will keep the window around for a while and may help.

thanks

---
co-chair http://ocjug.org/

[Chris Banford]

Thanks for the idea Ray, but it didn't have any effect. :-)
-Chris

[Paul King]

Maybe try the StringBuffer variation of consumeProcessOutput and
see whether you are getting any error messages from FileZilla.
Otherwise, I can only think of bumping up the delay numbers
temporarily (or adding in extra sleeps between the steps)
to see if that is causing problems - though it sounds like
you have tried those sorts of things.

Cheers, Paul.

[Ray Tayek]

At 02:51 PM 5/7/2010, you wrote:
>Thanks for the idea Ray, but it didn't have any effect. :-)

both simple cases seem to work for me (please see code below).

thanks

//main.groovy:
def exec() {
(1..3).each() {
println it
def proc = "cmd /c start ${it}.bat".execute()
proc.consumeProcessOutput()
proc.waitForOrKill( 2000 )
}
}
Run.exec()
//exec()

//run.groovy:
class Run {
static void exec() {
(1..3).each() {
println it
def proc = "cmd /c start ${it}.bat".execute()
proc.consumeProcessOutput()
proc.waitForOrKill( 2000 )
}
}
}

>>At 01:11 PM 5/7/2010, you wrote:
>> ...
>>>I'm just using a groovy script that is calling a method of a class
>>>that adds a new FTP User account to the FileZilla Server.xml file,
>>>and then calls the below restartServer().
>>>...
>>> def proc = 'cmd /c "c:\\Program Files\\FileZilla
>>> Server\\FileZilla Server.exe" /stop'.execute()
>>> ...
>>>
>>>Anything obvious that I'm doing wrong here? If I move these
>>>commands to the calling script (putting the Stop at the top and
>>>the Start & Reload at the bottom) then it works. Feels like it's
>>>some sort of timing issue...
>>
>>pm4ji, try using start: cmd /c start "c:\\Program Files\\FileZilla
>>Server\\FileZilla Server.exe" /stop
>>

>>this will keep the window around for a while and may help. ...

>
>---
>co-chair http://ocjug.org/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email