Darryl, Your remark about POJOs being part of the API prompted me to chime in -- William pretty much gave you the general answer, that Tomcat doesn't seem to be the best way to go for this (because everything is passed via http). I would point out that just as you can serialize/stream objects to disk and read them back again, you can do the same over network sockets -- in fact the code is nearly identical. So you can load up an object with all sorts of instance data on this end, open a socket connection to some other listening server (not tomcat, just a raw listener -- but that's only maybe 100 lines of code) and write(...) the object to the stream, then read it out on the other end. The serializing/deserializing concept of java will automagically reconstitute the object on the receiving end. (Assuming they both have access to the class at runtime).
I seem to recall there being a very nice tutorial for java sockets on the sun java website; you could probably work up the basic communication in under an hour. Good Luck, Patrick On 8/11/05, Will Hartung <[EMAIL PROTECTED]> wrote: > > From: "Paul Wallace" <[EMAIL PROTECTED]> > > Sent: Wednesday, August 10, 2005 6:38 PM > > > Hi and thanks for that, > > That's the crux of my question! The data (I am unsure of the > > protocol it is delivered in) is sent at random points in time i.e not from > > any request. I wish to create particularly the client (server B) that > > listens for this data. I (mistakenly) mentioned server A to mimic the data > > pushes. I can write something to fire off data at intermittent times, but > I > > am more interested in how to capture that data, when no request has been > > made. This is the reason why I first questioned on Sockets. > > Perhaps I should have been clearer from the off! > > Yea, that "protocol" detail is kind of important. > > As others have said, Tomcat is set up for HTTP requests, and pretty much > ONLY HTTP requests. As much as it would be nice to extend GenericServlet to > work with ANY protocol, in truth it just doesn't happen and is not really > practical. The GenericServlet interface is still pretty heavily tainted by > HTTP. > > If you want to listen to HTTP datastreams, then Tomcat is the hot tip. > > If not, then you can start with the Jakarta Avalon project (which is > basically dead). Avalon was a lower level container designed to be the > boiler plate so you can focus on implementing your own protocols. While the > actual Avalon project is dead, the current project page shows you how it has > forked into several other projects, so you can use that as a starting point > to perhaps hunt down a framework to more easily handle your own protocol. > > Now, to be fair, if you don't have any real VOLUME of data (lots of > connections, high load, vs just the occasional chit-chat), you may well be > able to write a simple server in just plain Java. A simple server is not > difficult, and there are no doubt several examples on the net. Listening to > a socket is no longer the rocket science it once was. Just depends on your > tolerance for getting it to work vs learning a framework. > > Finally, if you REALLY want to dig in to the Tomcat internals, you can break > it into little pieces and bits and hammer to fit to support your protocol. > > Also, there's the book "How Tomcat Works" which is actually a pretty good > book if you want to know how to write a network server in Java. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
