I read January thread about debugging (mostly IDEs)
and liked the idea of starting WebLogic's t3 and
catching exceptions.
My question is, IDE's and unit testing aside, -- you
are running beans in development/production -- let's
say in Unix --, there are problems, you'd like to get
some idea of what is happening. You will need to have
written some code to help debug/trace what is
happening in the server. It would be nice to switch
it on by bean type or turn it on globally without
having to bring down production.
Any ideas on how to do this? I thought of writing a
utility to read through our .java files finding only
ones that implement SessionBean or EntityBean and then
adding a method call at the start of most methods if
it wasn't already there. The method call would
include the method name as a string and other helpful
info.
But what should the method check? Could the list of
bean types to debug be kept in a properites file?
Keeping it in a database would be ok but might slow
down things quite a bit.
If the method is static then concurency problems could
be introduced, so perhaps it should be added as a
local private method by the utility? Should it talk
to one of a number of stateless Session beans that log
the timestamped trace to its open file?
Are there any other ideas that people have used to
help debug what the environment as a whole is doing
and what's happening as things slow down/stop/etc?
I'm guessing that a number of implemenations have
built some debugging/tracing facilities into their
code. Care to share a tip?
Thanks,
- Mark
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
