On Wed, Nov 4, 2009 at 3:43 PM, Darin <[email protected]> wrote: > > Hello again, everyone. > > Tomcat is now installed and running. Unfortunately, I am getting > exactly the same behavior as before. The code to process the returned > value on the client is as follows: > securityService.validatePassword(message, new > AsyncCallback<CompressedMessage>(){ > @Override > public void onFailure(Throwable caught) { > displayErrorBox("Server error","Unable to > contact the server."); > return; > } > @Override > public void onSuccess(CompressedMessage result) { > String > replyString=compression.Decompress(result); > and so on... > > I am getting the top error box every time: "Unable to contact the > server".Technically, Tomcat is not throwing an error; it just can't > seem to process the RPC. This is the same behavior that it was > exhibiting before when I was using the C version of the Apache server. > With respect to jhulford's suggestion: I changed the java.library.path > in Tomcat using the command > -Djava.library.path=C:\Program Files\Apache Software Foundation\Tomcat > 6.0\webapps\ROOT > Then I stopped and restarted the Tomcat service and got exactly the > same behavior. (That was depressing because I really thought that was > going to work.) And I'm out of ideas again... Anything else I should > try? > > Best, Darin >
I'm not a Tomcat expert. However, there should be an error log. Make sure to check that. The nominal GWT project proves GWT's RPC logic. Create a new project. If you're not using Eclipse, you should be able to create a new project using the command line tools. Don't do anything to the project except deploy the WAR to your Tomcat server, and verify that the nominal project works. Start with the nominal project and work upward from there. > > > > > On Nov 4, 1:17 pm, Darin <[email protected]> wrote: > > Hi, guys. Thanks again everyone for your help. (Sorry if the thanking > > gets repetitive, but I've seen so many impatient and ungrateful > > nimrods on forum pages like these that I'd prefer to be overly polite > > than seem unappreciative.) > > > > From your responses, I believe that I may have a solution to the > > problem. The Apache server that I downloaded was the C version of the > > server which, it appears, does not support Java at all. When I > > download and install Tomcat, hopefully one issue will go away. > > However, there is the other issue that the Java is calling native code > > from a directory that the Java environment will not be aware of. This > > may be slightly harder to remedy, but if I understand "jhulford" > > correctly, it is possible to determine what the java.library.path is > > and place the C/C++ dll there. I will research this and get back to > > everyone with the results. > > > > Best, Darin > > > > On Nov 4, 6:39 am, Jeff Chimene <[email protected]> wrote: > > > > > On Wed, Nov 4, 2009 at 7:03 AM, Darin <[email protected]> wrote: > > > > > > Hi, Adrian and Jeff. > > > > > > Thanks again for the help from both of you. I greatly appreciate it. > > > > > No prob. > > > > > I'm still looking for two answers: > > > 1. What error are you getting when running using Apache? > > > 2. What Java server are you using outside development mode? Apache > doesn't > > > support Java. When in development mode, you're using Tomcat. Even when > > > compiling and running, you're still (probably) using Tomcat (unless > you're > > > using -noserver, and it doesn't sound like you are). > > > > > > I have two files in the server. One of them is SecurityServiceImpl > and > > > > the code looks like this (skipping the includes, etc.): > > > > public class SecurityServiceImpl extends RemoteServiceServlet > > > > implements SecurityService { > > > > private static NativeCodeClass nativeCode=new > NativeCodeClass(); > > > > private CompressClass compression=new CompressClass(); > > > > @Override > > > > public CompressedMessage validatePassword(CompressedMessage m) > { > > > > String message=compression.Decompress(m); > > > > String > username=message.substring(0,message.indexOf(',')); > > > > String password=message.substring(message.indexOf(',') > > > > +1,message.length()); > > > > String > returnString=nativeCode.validatePassword(username, > > > > password); > > > > CompressedMessage > > > > replyMessage=compression.Compress(returnString); > > > > return replyMessage; > > > > } > > > > } > > > > The other file is called NativeCodeClass and the code looks like > this: > > > > public class NativeCodeClass { > > > > static { > > > > System.loadLibrary("SolverLibrary"); > > > > } > > > > public native String validatePassword(String username, String > > > > password); > > > > } > > > > > > I have doublechecked that both of these files are definitely in the > > > > server code (and these are the only files in the server code). When I > > > > run the code from within hosted mode, this code works (i.e. finds the > > > > SolverLibrary and checks the entered password, etc.). And (here comes > > > > the important part), when I compile it and run it from within the > > > > browser by pressing the Compile/Browse button from inside hosted > mode, > > > > it works just fine as well inside Mozilla. It fails when I copy the > > > > directories to another place on the hard drive. Unless I am seriously > > > > confused (and I have to admit that this is a possibility), if the > > > > problem was one where the native code was executing inside of > > > > Javascript, it could not run correctly from inside the browser after > > > > the Compile/Browse step. > > > > > > It occurs to me that maybe my RPC calls to the server are not > > > > functioning correctly when I try to move the folders to somewhere > else > > > > on the hard drive. Is there an obvious reason why that might happen? > > > > Thanks for all your help. > > > > > > Darin > > > > > > On Nov 4, 1:56 am, Adrian <[email protected]> wrote: > > > > > Hi guys, > > > > > > > I think Darin might not be up to speed with the differences between > > > > > server side and client side stuff and also how web environment > differs > > > > > from the desktop environment. You might know this already but if > not > > > > > it might clear a few things up. > > > > > > > When developing an application with GWT in Eclipse you need to be > > > > > aware of two distinct parts, the client side and the server > > > > > side.Eclipse should setup a couple packages for these parts when > you > > > > > create a GWT project so you don't get confused. The client side is > > > > > compiled from java to javascript that is designed to run only in a > > > > > browser. That means the resulting javascript has all the > limitations > > > > > enforced by the browser, which includes no way to run native code. > So > > > > > GWT compiles the java in the client package to javascript, which is > > > > > run in the browser once the browser requests it from your webserver > > > > > (apache in this case). Because apache isn't a java application > server > > > > > (like tomcat, jetty etc) it cannot directly run the server side > java > > > > > (stuff in the server package). > > > > > > > Things get a little confusing when you're running in hosted mode > > > > > because a lot of fancy stuff is happening in the background so it > > > > > appears the java code you have written for the client is running > > > > > directly, it basically skips the compiling to javascript step and > runs > > > > > the client code as java. Because java has the ability to run native > > > > > code it will appear to work, however once compiled to javascript it > > > > > wont because javascript doesn't have the functionality (mainly for > > > > > security reasons). > > > > > > > Also don't be fooled by javascript's name, it is a very different > > > > > language than java! > > > > > > > So, you can't run native code from javascript in a browser, but you > > > > > can run it from java on the server side. A possibly solution could > be > > > > > to use GWT's Remote Procedure Calls to run the native code on the > > > > > server, then get the results sent to back to the client. > > > > > > > Hope that helps, > > > > > Adrian > > > > > > > On Nov 4, 1:25 pm, Jeff Chimene <[email protected]> wrote: > > > > > > > > On Tue, Nov 3, 2009 at 3:47 PM, Darin <[email protected]> > wrote: > > > > > > > > > Hi, Jeff. Again, thanks for the responses. I have researched > what the > > > > > > > classpath means (and I assume you mean the directory or > directories > > > > > > > where the JRE looks for possible libraries to use) > > > > > > > > Yes > > > > > > > > > and I have manually > > > > > > > set the classpath to be the directory where the library > resides. > > > > > > > Unfortunately, that still did not change anything. > > > > > > > > I didn't expect it would. > > > > > > > > > To the best of my knowledge, the server itself isn't supposed > to run > > > > > > > the code. > > > > > > > > The code that you posted originally (the call to LoadLibrary) > should > > > > only > > > > > > run on the server. It might also run on the client in hosted > mode, but > > > > > > that's not what you want in the Long Run. > > > > > > > > According to the GWT website (please correct me if I am > > > > > > > > > wrong, and it is very possible that I am wrong), the code is > executed > > > > > > > as Javascript from within the browser. > > > > > > > > Correct, as long as you;re not trying to call LoadLibrary. > > > > > > > > The Javascript that is already > > > > > > > > > theoretically executing from within the browser is supposed to > > > > execute > > > > > > > the native code. > > > > > > > > I don't know what you mean by "native code". Do you mean the > compiled > > > > C++ > > > > > > code in SolverLibrary? If so. the browser will not execute that > native > > > > code > > > > > > (at least not via GWT compiled Javascript) > > > > > > > > For some reason, it finds the code on the computer on > > > > > > > > > which I am developing the app, but cannot find the native code > when I > > > > > > > copy it directly to another machine (into the directory where > Apache > > > > > > > looks for its source files). I have copied the SolverLibrary > into > > > > > > > every subdirectory of the main Apache library that I can find > but the > > > > > > > native code still refuses to execute. I'm going to try > installing > > > > > > > Eclipse and GWT on the server machine and see if that helps. > Wish me > > > > > > > luck... > > > > > > > > I think we're back to the issue that Apache doesn't have a JRE, > so it's > > > > not > > > > > > finding the code that calls LoadLibrary. I think that what's > happening > > > > is > > > > > > that in hosted mode, you're using Tomcat, a Java server which > will find > > > > and > > > > > > execute the code that calls LoadLibrary. When you move to GWT > noserver > > > > mode, > > > > > > then you're using Apache. > > > > > > > > What is the error you get when you run the code using an Apache > server > > > > > > instance? > > > > > > > > > Best, Darin > > > > > > > > > On Nov 3, 2:14 pm, Jeff Chimene <[email protected]> wrote: > > > > > > > > Hi Darin: > > > > > > > > > > After re-reading your first post, I think you're already in a > > > > > > > client-server > > > > > > > > environment. I am confused by the following:> I am running > Windows > > > > XP and > > > > > > > using Apache as my http server. Any ideas for > > > > > > > > > > where I should put the native library so > > > > > > > > > > > that the Javascript can find it? > > > > > > > > > > Your Apache installation probably doesn't run Java > > > > > > > > I think the reason it works in hosted mode is that your > hosted mode > > > > > > > server > > > > > > > > is a Java server: Tomcat. > > > > > > > > > > On Tue, Nov 3, 2009 at 2:59 PM, Jeff Chimene < > [email protected]> > > > > wrote: > > > > > > > > > > > On Tue, Nov 3, 2009 at 2:36 PM, Darin < > [email protected]> > > > > wrote: > > > > > > > > > > >> Hi, Jeff. > > > > > > > > > > >> Thank you so much for responding to my question. > > > > > > > > > > >> Perhaps I'm getting confused by the jargon. The > "SolverLibrary" > > > > that I > > > > > > > > >> wrote is written in C/C++ and compiled by Visual Studio > into a > > > > ... > > > > read more ยป > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
