tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Running Swing app under Tomcat 6 on Linux
Date Tue, 01 May 2012 16:44:12 GMT
----- Original Message -----
> From: "Christopher Schultz" <>
> To: "Tomcat Users List" <>
> Sent: Tuesday, May 1, 2012 10:18:22 AM
> Subject: Re: Running Swing app under Tomcat 6 on Linux
> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message