Looking back, I was perhaps being a bit harsh. The thing is: most developer communities do not react well to a vague description of something that "doesn't work as expected" without background information. We always tell kids to do their own homework, not write it for them ;-)
What exactly are you trying to accomplish? What is JADE, and how does your Java code interact with it? I have quite a bit of experience getting revTalk to exchange information with Java processes - bit it all stands or falls with the intended architecture. If your Java code is a simple command-line tool for one-off jobs, you can use the 'shell' function to call it with parameters and retrieve the output. If your interaction needs to be more elaborate, topology comes into play. Assuming that the Java program runs on the same machine, you can opt for inter-process communication via standard input/output (your Java code uses the System.in object to read the data from and the System.out object to write the data back to the rev-based application that uses 'open process', 'read from process', 'write to process' and 'close process' commands to send data to your Java program and retrieve results. If the Java program runs on a different machine, your best bet is socket communication. For the Java side, I recommend you pick up the book 'TCP/IP Sockets in Java' (ISBN: 978-0-12-374255-1). On the revTalk end, you'll want to look at the 'open socket', 'read from socket', 'write to socket' and 'close socket' commands to exchange the data over the socket. What it all boils down to, is picking a method of communication, and a protocol that describes the interaction: which side takes the initiative and in what format do you send the request and receive the reply. You can dream up your own protocol, copy the HTTP client-server model, exchange the data as plain text or structured in XML. Speaking of XML, why not rely on SOAP? Your Java code could be housed in a Glassfish application server, and rely on Web Services technology to 'post' data from rev to the app server - where your POJO classes transparently offer services to any SOAP-capable client. First determine your goal, and then we can help you figure out the best way to achieve that goal. There is more than one way to skin a cat, as the saying goes... Jan Schenkel ===== Quartam Reports & PDF Library for Revolution <http://www.quartam.com> ===== "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) --- On Sat, 3/20/10, Jan Schenkel <janschen...@yahoo.com> wrote: > Hi Zeeshan, > > My apologies if this sounds a bit blunt, but from the > exchanges it seems to me that you are not only a beginner in > revTalk, but not very experienced with Java either when it > comes to socket programming and starting daemon processes > and its classpath challenges. > > At RunRevLive'09 I gave a presentation on how revTalk and > Java can interact in various ways. You can download the > slides and example code from the downloads section of my > website: > <http://www.quartam.com/downloads.html> > > Come to think of it, that's probably how you assembled > those first bits of code: setting the defaultFolder to the > path of the stack is a trick I used there to keep everything > together in a single folder and reduce scripting complexity. > Not something a newbie will find on day one ;-) > > For this to work, the compiled Server.class file must be in > the same directory as the rev stack; if it's sitting > somewhere in your NetBeans project directory, it is not > going to find it. > > Merely repeating that something doesn't work, is not going > to resolve your situation: take a step back, think through > the different concepts and learn more about processes and > socket programming. > > Jan Schenkel > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
