Re: GWT Native Code Deployment

Hi, guys.

So here is what I've "accomplished" thus far. I've loaded the
DynaTable sample app directly from the GWT website. I've tested that
this app works in (a) hosted mode, (b) compiled from hosted mode, and
(c) actually deployed on the Tomcat server. So far, so good. I then
added the following class:

package com.google.gwt.sample.dynatable.server;

public class NativeCodeClass {
static {
System.load("C:\\Documents and Settings\\Darin\\My Documents\\eclipse
\\workspace\\DynaTable\\war\\SolverLibrary.dll");
}
public native String validatePassword(String username, String
password);
}

and added a single line to SchoolCalendarServiceImpl.java (which is
definitely server code):

private static NativeCodeClass nativeCode=new NativeCodeClass();

I promise that the SolverLibrary is in the location I specified.
(Because I'm using the load function rather than the loadLibrary, in
theory it shouldn't matter where the java.library.path is pointing
to.) I also promise that there is a function in SolverLibrary called
validatePassword with that signature. Though the entire program
doesn't crash (kudos to the GWT programmers), the RPC call fails to
execute and retrieve the table. I am now convinced that the problem is
pretty much entirely due to the fact that the server side code is
having trouble interacting with native code (i.e. loading a simple
DLL). I have looked up this procedure via JNI (and have tried the
LoadLibrary version of the system call as well) and it appears as if
I'm doing everything correctly. Do any of you know if there exists a
sample application that loads a native code DLL that I can test on my
machine? Thanks for all your suggestions thus far.

Best, Darin

On Nov 5, 6:27 am, jhulford <jhulf...@gmail.com> wrote:
> Make sure you're wrapping the library path in quotes too - otherwise
> you just set the path to C:\Program.  You also probably don't want to
> completely replace the library path with you own because there's some
> optimized bits of Tomcat that use jni.  Google 'jni tomcat' and you'll
> get lots of information about how to go about doing this...here's a
> good starter:http://wiki.apache.org/tomcat/HowTo#I.27m_encountering_classloader_pr....
>
> I'd also do like what Jeff said...get a version of your web app
> running sans the native stuff and work forward from there since it
> sounds like you might have other issues besides just the jni loading.
>
> On Nov 4, 4:43 pm, Darin <daring90...@gmail.com> 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
>
> > On Nov 4, 1:17 pm, Darin <daring90...@gmail.com> 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 <jchim...@gmail.com> wrote:
>
> > > > On Wed, Nov 4, 2009 at 7:03 AM, Darin <daring90...@gmail.com> 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 <ahay...@gmail.com> 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 <jchim...@gmail.com> wrote:
>
> > > > > > > On Tue, Nov 3, 2009 at 3:47 PM, Darin <daring90...@gmail.com> 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
>
> ...
>
> 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 google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---