 |
An unorthodox approach to logging in application server
Posted by kirillcool on February 09, 2006 at 02:52 PM | Comments (3)
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 :)
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Those who even thought about that should be seriously punched and kicked out of the project. In many cases app servers runs on a head-less box and nobody would want to hunt down all the side effects of such "advanced" logging up there.
After all it is not that difficult to implement your own appender for log4j or most of other logging systems to show more friendly UI then one you got by tailing log files from the command line. The easiest way would be just email all the log events above certain ceverity using existing email appender.
Posted by: euxx on February 09, 2006 at 03:19 PM
-
At least you can catch the HeadlessException thrown by JFrame :)
Posted by: gfx on February 09, 2006 at 05:20 PM
-
euxx,
Lighten up - you're making the same mistake i did. You're looking to hard for the reasons not to do it and applying a generic app-server scenario.
The machine in question was WinXP dev box (local dev station). The code in question existed about half an hour and then was gone. See the list of the "reasonable" or "accepted" things to do. You may add sending a JMS message or using a JMX console there - but it's exacly the mindset that needs to be refreshed. The log4j approach is most certainly not the easiest way for the specific scenario that was at hand - it's just the way you got accustomed to :)
Posted by: kirillcool on February 09, 2006 at 11:57 PM
|
java.net RSS Feeds
