tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Running Swing app under Tomcat 6 on Linux
Date Tue, 01 May 2012 14:18:22 GMT
Hash: SHA1


At this point, we're way off-topic but I'll keep playing if you want to ;)

On 4/30/12 12:46 PM, wrote:
> Thanks for the input.  I guess I should give more rationale on why 
> I want to do this.  My webservice(s) use an open source project 
> that acts as a DB engine for retrieving data from the DB (google 
> 'zeidonjoe' if any of you are interested).  The data engine has a 
> browser that lets a developer view all the retrieved data in a 
> structured GUI.  In a way it would be like viewing all your active
>  Hibernate objects, showing data and relationships.  It can be a 
> very powerful tool while debugging.  The browser is dynamically 
> loaded+started by the data engine and it (the browser) has access 
> to the engine's internal objects so that the DB data can be 
> displayed.

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.

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.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


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

View raw message