A colleague of mine entered our room a couple of days ago and asked me this: can he open a Swing frame from the application server in order to view the request that he got (a pretty big XML string)? Sounds strange, right? So many reasons not do this:

• What happens with this code in production?
• Why not use Eclipse debugger, copy the request to XMLSpy and view it there?
• Why not configure the log level of the specific class to WARNING, copy the message from the app server console (WebLogic 8.1 in this case) and do the above (with XMLSpy)?

And that's not all - after working with application server and writing the back-end functionality, you come to think in certain terms of what is right and what is wrong. You work with the database through the db layer, you don't start threads on your own, you think in XML and web services, you send a message to your dog via JMS (OK, went a little too far :) Of course you expect the full power of J2SE available to you in addition to J2EE stack, you just view the application server as this really powerful cluster with a terminal window attached to it.

After thinking half a minute about this, me and our GUI expert have started to think - perhaps the application server is not allowed to open Swing frames? But why not - it runs on the local machine, it has full access to the file system, it has full access to the DB. Most certainly you need much less permissions to open a frame. Surely if you leave this code in production it will open a few thousand frames (one per each request) and let the machine die happily, but that's not the point. The point is that this technique was suited very well to the particular problem, but it was so unorthodox that it took us quite a few minutes to agree that it should be possible to do.

Eventually it turned out that there was no problem in opening a JFrame from inside an EJB implementation class. A little something to think about... Perhaps a look-and-feel for the EJB 3.0 :)