groovy

NPE in GroovyClassLoader

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0-RC-1
  • Fix Version/s: 1.0
  • Component/s: None
  • Labels:
    None
  • Environment:
    groovy svn head
  • Number of attachments :
    1

Description

I was trying out my native launcher's ability to use other jvm than the one pointed to by java home. The feature seems to have stopped working - groovy throws an NPE from GroovyClassLoader when using that option.
Attached is a patch that removes the NPE so the real exception can be seen.

I am not sure whether this is a bug in the native launcher or in the groovy java code. It is fairly easy to reproduce - copy the groovy.exe (or platform equivalent executable) to the bin dir or groovy executable and say something like this:

bin\groovy.exe -jh c:\programs\Java\jdk1.5.0_09 -v

The error produced (after fixing the NPE) is:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, c:\programs\Java\jdk1.5.0_09: c:\programs\Java\jdk1.5.0_09 (Access is denied)

1 error

Any ideas? How can I get the whole stack trace? -d does not seem to cut it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

what happens if you run it normally ?

Show
blackdrag blackdrag added a comment - what happens if you run it normally ?
Hide
Permalink
Antti Karanta added a comment -

If by "normally" you mean w/out the -jh option, it works just fine.

This is a little baffling as all the -jh option does is that it loads the jvm from a different location than the one pointed to by JAVA_HOME. The jvm obviously starts up fine as groovy starts, but something goes wrong after that.

But getting the full stack trace might help - how do I get that?

If -d should do it I propably have a bug in the launcher that consumes it before it ends up to the java side.

Show
Antti Karanta added a comment - If by "normally" you mean w/out the -jh option, it works just fine. This is a little baffling as all the -jh option does is that it loads the jvm from a different location than the one pointed to by JAVA_HOME. The jvm obviously starts up fine as groovy starts, but something goes wrong after that. But getting the full stack trace might help - how do I get that? If -d should do it I propably have a bug in the launcher that consumes it before it ends up to the java side.
Hide
Permalink
Antti Karanta added a comment -

Hmm, I think I got it: it seems that the -jh option is broken and the launcher passes the value of that param to the java side. The java side seems to think it is the script to run, so it tries to run something like this:

groovy c:\temp

which obviously does not work since a directory can not be interpreted as a script.

I'll fix the bug in the launcher, but maybe this would be a place to improve on the error message? Something like

c:\temp is a directory and can not be run

?

Show
Antti Karanta added a comment - Hmm, I think I got it: it seems that the -jh option is broken and the launcher passes the value of that param to the java side. The java side seems to think it is the script to run, so it tries to run something like this: groovy c:\temp which obviously does not work since a directory can not be interpreted as a script. I'll fix the bug in the launcher, but maybe this would be a place to improve on the error message? Something like c:\temp is a directory and can not be run ?
Hide
Permalink
blackdrag blackdrag added a comment -

first I thought it might be related to GROOVY-1595 but that is something different. Not so easy to tell. I guess if executing the class your launcher starts via java is normally working, well then it is most possibly a problem in your launcher.

Show
blackdrag blackdrag added a comment - first I thought it might be related to GROOVY-1595 but that is something different. Not so easy to tell. I guess if executing the class your launcher starts via java is normally working, well then it is most possibly a problem in your launcher.
Hide
Permalink
blackdrag blackdrag added a comment -

I will close this issue then, please open a new one for the message reporting problem.

Show
blackdrag blackdrag added a comment - I will close this issue then, please open a new one for the message reporting problem.
Hide
Permalink
Antti Karanta added a comment -

Did you apply the patch? If you don't, you'll get an npe when trying to do something like:

groovy c:\temp

even without the native launcher.

Show
Antti Karanta added a comment - Did you apply the patch? If you don't, you'll get an npe when trying to do something like: groovy c:\temp even without the native launcher.
Hide
Permalink
blackdrag blackdrag added a comment -

changed locally yes, my next commit will include it

Show
blackdrag blackdrag added a comment - changed locally yes, my next commit will include it
Hide
Permalink
blackdrag blackdrag added a comment -

Antti's fix is in GCL now.

Show
blackdrag blackdrag added a comment - Antti's fix is in GCL now.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.