On Wed, 2014-10-29 at 08:28 -0400, Jason Ricles wrote: > foo is not a webapp, it is a separate program running on the computer as a > daemon. It has to do this stuff for it needed to be ran like this. bar is > basically the gui to the daemon, providing what is happening on the machine > to someone at another computer, since the machine is headless these > programs are being ran on. So I am curious as to how having my foo program > running outside of bar how it can interact using websockets? So far I have > seen that they are disconnected and have no clue about each other outside > of using RMI. >
A java program can be a websocket client with out being a webapp. Perhaps this example will help: http://stackoverflow.com/questions/26452903/javax-websocket-client-simple-example You would need the JEE 7 websocket jar which presumably is included in Tomcat 8 -- or use the appropriate Maven dependencies. And as Chris pointed out, JSON is fairly ubiquitous and easy to deal with. RMI could work and is simple enough. There are a few downsides worth considering: 1) it's strictly java-to-java IPC, so no other technologies (e.g. .NET) can participate down the road; 2) it's not firewall friendly -- but that would only matter if there was a fw between foo and bar; 3) it's not hip and cool -- not sure how widely used it is anymore outside of EJB (do people still write EJBs?). Did you say earlier that foo would need to send unsolicited alerts at some point -- i.e. send alerts even when there's no client listening? That could possibly complicate the design in that I believe the ws server endpoint's life begins only in response to a client connection. (I'm thinking of the server endpoint for the browser here.) Thus such alerts would need to go somewhere until a client shows up wanting to see them (e.g. a database). And if that's the case why not send all of them there. Sounds like you may have some design issues to work out and we don't have enough details to be of much help. --tim. > On Tue, Oct 28, 2014 at 6:55 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Jason, > > > > On 10/28/14 3:06 PM, Jason Ricles wrote: > > > Chris, foo has to run as a daemon outside of tomcat. It will be > > > interacting with low level drivers through jni. > > > > While interesting, it's not terribly relevant. > > > > > I was looking at trying to do that with making a client endpoint > > > in my daemon but i was having trouble getting it to connect to the > > > websocket server. > > > > Maybe you should start there: get your foo daemon talking to your web > > application via Websocket and I think you'll learn a lot about > > Websocket in general and probably end up with a better webapp to boot. > > > > Thanks, > > - -chris > > > > > On Tue, Oct 28, 2014 at 12:21 PM, Christopher Schultz < > > > ch...@christopherschultz.net> wrote: > > > > > > Jason, > > > > > > On 10/28/14 9:06 AM, Jason Ricles wrote: > > >>>> Ok so here is the problem I have been spinning my wheels on > > >>>> for day let me just lay it out. > > >>>> > > >>>> I have a daemon written in java running lets call it foo for > > >>>> simpleness on a linux machine that has the tomcat server > > >>>> running. On the tomcat server is a WAR file for a webapp > > >>>> called bar. In that webapp is a webpage with JavaScript > > >>>> websocket communication that connects to a websocket server > > >>>> that is also a part of the WAR file. So I have a webpage and > > >>>> a websocket server communicating with each other. > > >>>> > > >>>> I want the foo daemon and the websocket server on bar (web > > >>>> application) to be able to communicate with each other. Is > > >>>> there any way outside of sockets to have foo and the > > >>>> websocket server on bar do this? > > > > > > Dumb question: why can't foo just be a Websocket client? Make a > > > ws:// connection to your web application in Tomcat and then > > > two-way communication is possible. Take whatever values from either > > > side and push them over the wire. > > > > > > Use JSON or something dirt-simple as your data encapsulation > > > language: it's standard, well-understood, and has parsers and > > > serializers readily available for many different languages. It's > > > also pretty much backward- and forward-compatible since everything > > > is pretty much a named value map, so you can add/subtract fields at > > > will without having to rewrite the communication protocol or do a > > > lot of extra work in either the client or the server. > > > > > > -chris > > > > > >>>> On Tue, Oct 28, 2014 at 8:59 AM, Martin Grigorov > > >>>> <martin.grigo...@gmail.com> wrote: > > >>>> > > >>>>> On Tue, Oct 28, 2014 at 2:51 PM, Jose María Zaragoza > > >>>>> <demablo...@gmail.com > > >>>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> 2014-10-28 13:44 GMT+01:00 Jason Ricles > > >>>>>> <jgr...@alum.lehigh.edu>: > > >>>>>>> > > >>>>>>> Martin, > > >>>>>>> > > >>>>>>> I can not use hazelcast due to regulations I have to > > >>>>>>> abide by, is where > > >>>>>> any > > >>>>>>> other built in way besides sockets that will allow me > > >>>>>>> to share data > > >>>>>> between > > >>>>>>> the two processes? > > >>>>>> > > >>>>>> > > >>>>>> You could use an embedded ( or not ) messaging broker ( > > >>>>>> like ActiveMQ ) . Or any kind of in-memory database > > >>>>>> > > >>>>> > > >>>>> But this will be again socket based communication. > > >>>>> > > >>>>> > > >>>>> Let's start from the beginning: What is your use case ? > > >>>>> What value will have a deserialized session in the second > > >>>>> process ? > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Tue, Oct 28, 2014 at 8:24 AM, Martin Grigorov < > > >>>>>> martin.grigo...@gmail.com> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> In this case you will have to share the data between > > >>>>>>>> the processes. A simple and easy solution would be to > > >>>>>>>> use http://hazelcast.com/, > > >>>>> for > > >>>>>>>> example. > > >>>>>>>> > > >>>>>>>> On Tue, Oct 28, 2014 at 2:06 PM, Jason Ricles < > > >>>>> jgr...@alum.lehigh.edu> > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>>> No, > > >>>>>>>>> > > >>>>>>>>> it is external as in it is running in a daemon on a > > >>>>>>>>> linux machine > > >>>>>> where > > >>>>>>>> the > > >>>>>>>>> tomcat server is also running. > > >>>>>>>>> > > >>>>>>>>> On Tue, Oct 28, 2014 at 4:35 AM, Johan Compagner < > > >>>>>> jcompag...@servoy.com> > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> I would like to be able to access my sessions > > >>>>>>>>>>> from an external > > >>>>>> java > > >>>>>>>>>> class, > > >>>>>>>>>>> however each time I do sessionList.getsize() it > > >>>>>>>>>>> keeps coming > > >>>>>> back as > > >>>>>>>> 0, > > >>>>>>>>>> but > > >>>>>>>>>>> there is an active sessions. Is there any way I > > >>>>>>>>>>> can access the > > >>>>>> active > > >>>>>>>>>>> sessions in tomcat from an external java > > >>>>>>>>>>> class? > > >>>>>>>>>>> > > >>>>>>>>>>> Jason > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> What is an external java class? Is it in the same > > >>>>>>>>>> class loader? > > >>>>> so > > >>>>>> it > > >>>>>>>> is > > >>>>>>>>>> just part of the webapplication? then the above > > >>>>>>>>>> approach should work fine > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -- Johan Compagner Servoy > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > --------------------------------------------------------------------- > > >>>>>> > > >>>>>> > > > > > >>>>>> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >>>>>> For additional commands, e-mail: > > >>>>>> users-h...@tomcat.apache.org > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> --------------------------------------------------------------------- > > >> > > >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> > > >> > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > Comment: GPGTools - http://gpgtools.org > > > > iQIcBAEBCAAGBQJUUB7PAAoJEBzwKT+lPKRYRHMQALE7FFu/TAJ2RSJ9PFMBL0BZ > > tlfNH05K67/LeFRF+XXSkEXt6wtGiUyrWAqW0sMwzD53d+utzCeEAdBweIx+FqPN > > epMXNgPSmLWVYSRlCF1Cc5AjD2XIkxydifVHoGficH+EEvNN7Z+RboC3/H7VU1T+ > > bO0//oj7Tne+v8V/sgdH7vvW/3ERbncMQU60aLAIMxVkiFYhZH3tAoGZ1TGEBnd8 > > 4fkxzCnJHF0hCvHhZqelVI1yvSBDQGGDPc8NFfoXyJ1UkM/MT1ALeqPogajm+yRy > > TEP5rSNCzfr4Vx2qr9BY577u9/4V2V2t0GxRjTcY5o4E/XSe37Cxzj0PdAxd/Rry > > s7hnBP0lQbSixNEoMURxxx1hq5KW2nAxhiBP/GsZGrT5u2QbMF1Ca5tW3pPCyBWn > > dWu/VT3i/fKbV9Sw64a2yr1rHUDUD3mg64nUp0DL49ZJV2aY6HOcdCH+y1I3PXLS > > yb2+VCjbjQ3KZRxYHh+1FKrjX0C9+QoyUb6tDvm1EDsAzOgR/ornJR4CUPQspEzX > > EMEjruHp+AOeDoXCBRBykUBiYjO2QYGNL/d+fTi/NqwB1/jt9B0dA2i7haPnobAO > > KP1at7aT6nD8Ps9DB8S7bKb2kULkVFq0gEXPiG/T6dLUCEKyeCTVDI/HFwCpqwQy > > +opr2qBrymRdt9k+mceb > > =OJQX > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
