----- Original Message ----- > From: "Christopher Schultz" <ch...@christopherschultz.net> > To: "Tomcat Users List" <users@tomcat.apache.org> > Sent: Tuesday, May 1, 2012 10:18:22 AM > Subject: Re: Running Swing app under Tomcat 6 on Linux > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > DG, > > At this point, we're way off-topic but I'll keep playing if you want > to ;)
I appreciate your input. Hopefully this isn't too far off and annoying other readers. :) > This sounds a lot like what jhat does (gives you access to underlying > data in a "browser"). You might consider using the jhat model and > providing a web-based interface for the same data instead of swing. jhat displays the raw data but the object browser allows the developer to view the data in a structured format. At the risk of using another lousy analogy, the application data is formated in a sort of high-functioning, hierarchical DOM. The browser lets the developer peruse (or, uh, browse) the data in this hierarchical format in real-time. It's sort of like the DOM viewer in Firebug (but better! of course). The first time developers see their data displayed by the browser there is almost always ooh-ing and ahh-ing. > If the swing interface makes the user experience that much better > (e.g. because you have certain widgets available, etc.) then you can > still use swing... just browsing a web-based interface (say, > delivering XML, binary data, or even serialized Java objects if you > really want to do that kind of thing). > > > The browser is written using Swing, originally on Windows, and the > > users (who are engineers) like it. Now I'm trying to get it > > working on Linux. A better long-term solution would perhaps be to > > create a JMX API but that's a lot of changes for something that > > already works on Windows. > > I don't think JMX is appropriate, here. > > > As always, engineering time is short and I'm looking for the > > quickest solution that doesn't confine me in the future. I'm open > > to any alternative ideas if they are relatively quick to > > implement. > > My suggestion would be to use HTTP as your transport protocol (you > *are* running on an HTTP-based application server so why not?) and > either a pure web-based interface or a swing app that actually runs on > the client and connects "remotely" (even if it's on the same box) to > the server. > > At this point, you may be too far down the road to re-tool, but I > think you'll gain more flexibility if your users don't have to be > sitting on localhost in order to browse this data. Plus, you won't > have to go through these crazy hoops to get it to work. I agree that some sort of remoting is the best solution. That just takes time and I was hoping for a quick solution. Woe is life. ;) If you want to continue this further feel free to contact me directly. I'm always open to informed opinions. For the long run I'm looking at http://sites.google.com/site/simpleremoting/home DG --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
