Re: GWT compiler call from Ant causes "Argument list too long" error

[ijonas]

Nothing like answering your own posts... My mistake was in the
classpath block off the  task

The correct form is:



















The faulty classpath block in my original post caused a classpath that
was several kilobytes in size.

Cheers,
Ijonas Kisselbach.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

GWT compiler call from Ant causes "Argument list too long" error

[ijonas]

Hi,

I've got a GWT project that I'm upgrading from 1.5.3. to 1.6.4 and
after adjusting my Ant build task as follows




















When running the task it causes the following error, from both inside
Eclipse as well as on the command line;

BUILD FAILED
java.io.IOException: Cannot run program "/usr/lib/jvm/java-6-
sun-1.6.0.14/jre/bin/java": java.io.IOException: error=7, Argument
list too long
at java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
at java.lang.Runtime.exec(Runtime.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec
(Execute.java:832)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:447)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:461)
at org.apache.tools.ant.taskdefs.Java.fork(Java.java:784)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:211)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:
288)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute
(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:
1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets
(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: java.io.IOException: java.io.IOException: error=7, Argument
list too long
at java.lang.UNIXProcess.(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)

A quick google reveals other Java systems (like Confluence) running
into issues with the fork-flag, so I tried setting fork=false, but
that generated allsorts of classloading nastiness.

I'm running 64-bit Ubuntu 9.04. Any help would be greatly appreciated.

Many thanks,
ijonas Kisselbach
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Unable to store "current user" in session due to badly behaving getThreadLocalRequest()

[ijonas]

Hi,

I'm trying to the remeber/store the current user in the HttpSession
object returned by RemoteServiceServlet.getThreadLocalRequest
().getSession(). Unfortunately
RemoteServiceServlet.getThreadLocalRequest() returns null, causing a
subsequent NPE when I call getSession().

public class ClientManagerImpl extends RemoteServiceServlet implements
ClientManager {

private HttpSession getHttpSession() {
return this.getThreadLocalRequest().getSession(true);
}

private void rememberLoggedInUser(User loggedInUser) {
HttpSession session = getHttpSession();
if (session!=null) {
session.setAttribute("currentUser", loggedInUser);
logger.info("session found and currentUser set");
} else {
logger.error("session not found!");
}
}
}

The idea is that the "login method" will call rememberLoggedInUser
(User) and store the user for future calls to the
RemoteServiceServlet.
All this code is being run from a Spring-based WAR on top of JBoss
4.0.3.

Are there any known issues with thread local variables or
getThreadLocalRequest() that is causing it to work in some conditions
and not in others ?

Many thanks,
Ijonas.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---