The Power and Pain of POJOs

Discussions

News: The Power and Pain of POJOs

  1. The Power and Pain of POJOs (13 messages)

    In "The Power and Pain of POJOs," Cay Horstmann describes his experiences writing a JavaEE application using EJB3 and JSF in a "couple of days," from the perspective of "Elvis," the prototypical programmer who just wants to get things done - and presumably the target programmer for whom EJB3 was designed. His first issue - meaning problem - was storing ordered lists in the database with JPA. He notes that Hibernate can do this fairly easily, and offers an enhancement request for Glassfish. (Note that this is more likely a specification issue, and not a specific Glassfish issue - and that votes on the enhancement request have promoted its importance.) After running through a set of non-issues (concerns he had going in, but that turned out to be all right, such as the transfer of data, whether lazy fetching worked properly for him, and JSF itself), he ran into what he described as a majour problem: stack traces, which tend to be verbose at best.
    The NetBeans debugger helped immensely. Without the ability to set breakpoints in the managed bean and session bean code, I would have had a truly miserable time. Something needs to be done. Glassfish has the wrong view of the world. It thinks that it is running a perfectly debugged application, and if something goes wrong, then it should dump it's life story to the log and sulk. Just imagine if the Java compiler took that approach to error handling. You'd compile, find no class file, and search for elusive clues in the log.
    The stack trace is an interesting point. JBoss has long been criticized for its stack traces that describe the exception's entire lifecycle in the container, and Glassfish is doing the same. As a "development server," Glassfish might be operating properly, by exposing the entire chain to developers, but that implies that JBoss is the same kind of thing, which is not backed up by JBoss' use in production environments. What's your view on stack traces in application servers? Where and to whom should they be exposed?

    Threaded Messages (13)

  2. Re: The Power and Pain of POJOs[ Go to top ]

    I think that some extra holidays would help. Are we talking about POJOs or stak trace ? Few ideas and well confused. Guido.
  3. Re: The Power and Pain of POJOs[ Go to top ]

    [quote]What's your view on stack traces in application servers? Where and to whom should they be exposed?[/quote] It is up to your application to choose what to do with a stack trace. We run JBoss in production environment and never had such an issue or even debate about it.
  4. what the[ Go to top ]

    now what this was all about?
  5. Re: The Power and Pain of POJOs[ Go to top ]

    I think you walk a fine line when you start dealing with stack traces. The problem lies in the fact that in some cases, 90% of the information in a strack trace from JBoss or Glassfish is useless the majority of the time to the majority of the people. So, we see a giant stack trace and think to ourselves that it's not useful to us so it should be turned off. I shouldn't have to look at it. Still, that information is useful to someone. There will come a day when there's a bug in the app server code itself and that stack trace will help point it out and it's this case that overly verbose stack traces are designed to support. It's difficult and (with all apologies to Mister Horstman whose textbooks I found very helpful in college) egocentric to say that the stack trace is too long, we need to find a way out of it because that stack trace is probably valuable to someone and therefore we should leave it in. Now, if the JBoss folk or Glassfish folk want to come back and say that the massively long stack traces are of no value, then I will gladly recant my statements. In the meantime, Mister Horstman was able to get around the problem by the judicious use of logging code which we should all be doing anyway...right? Lastly, I like the uberhuge stack traces. When I can scroll up to my exception and say "A ha, that's the problem" I often amaze my colleagues and employers. That's job security folks!! :)
  6. Re: The Power and Pain of POJOs[ Go to top ]

    I think you walk a fine line when you start dealing with stack traces. The problem lies in the fact that in some cases, 90% of the information in a strack trace from JBoss or Glassfish is useless the majority of the time to the majority of the people.
    Here's what I did for our AOP stuff, which could produce gigantic stacktraces "as-is". If an exception is thrown the AOP framework inspects it before re-throwing it. If the exception started within the framework nothing is done, otherwise all lines in the stacktrace related to the framework are removed, so that only application calls are left. That way stacktraces are usually very short, and when there *is* a bug in the framework one has enough detail to debug it. Works quite well, and is a policy that many other containers could/should adopt I think.
  7. Sure, stack traces are better than nothing. But if stack traces were so great, shouldn't the compiler show stack traces instead of giving sissy messages "Error x in file y line z"? Seriously, a stack trace is great in a DEPLOYMENT platform, but it is insufficient in a DEVELOPMENT platform. When the app server finds an error, it should (a) make an effort to trace back to the programmer artifact and (b) emit a message that a development environment can capture. I suppose the messaging could be piggy-backed onto a stack trace or a logger, but that seems a rather Neanderthal way of doing it. There are any number of better ways of sending error messages to a listener such as an IDE. Cay
  8. er...[ Go to top ]

    Just a quick comment, I have never once seen where a non-production server, library or framework produced too much debug info, but I have seen many that produce too little. Tons of debug info might take you an extra 10 minutes while too little takes you and extra 4 hours (or days).
  9. Re: er...[ Go to top ]

    Just a quick comment, I have never once seen where a non-production server, library or framework produced too much debug info, but I have seen many that produce too little.

    Tons of debug info might take you an extra 10 minutes while too little takes you and extra 4 hours (or days).
  10. Re: er...[ Go to top ]

    Just a quick comment, I have never once seen where a non-production server, library or framework produced too much debug info, but I have seen many that produce too little. Tons of debug info might take you an extra 10 minutes while too little takes you and extra 4 hours (or days).
    I have definitely seen environments with too much debug info. In one case, the application was producing on the order of 100GB of logs per day. That's not 10 minutes ;-) - Applications that pointlessly log too much will end up spending a large amount of their runtime resources on logging. - Real problems are burried when they occur in applications that log too much, because nobody notices the problems hidden in all the noise. Obviously, the key is to log the right amount of the right stuff, but good luck putting that into an easy-to-follow guideline! ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  11. Re: er...[ Go to top ]

    I have definitely seen environments with too much debug info. In one case, the application was producing on the order of 100GB of logs per day. That's not 10 minutes ;-)

    - Applications that pointlessly log too much will end up spending a large amount of their runtime resources on logging.

    - Real problems are burried when they occur in applications that log too much, because nobody notices the problems hidden in all the noise.

    Obviously, the key is to log the right amount of the right stuff
    +1
  12. Re: er...[ Go to top ]

    Obviously, the key is to log the right amount of the right stuff
    And since that probably changes which with each bug to solve, one has to love log4j; change the configuration to log what you are interested in, have it automatically reload and off you go. And about what should be logged: anything that a some what serieus decision (aka if statement) is made upon, so you can trace the path that was taken through the code. Personally calls and return values are not so interesting. Oh, and if some piece of code was not logging sufficiently enough, make sure that after you fixed the bug, it also logs correctly.
  13. Re: er...[ Go to top ]

    >I have definitely seen environments with too much debug info. In one case, the application was producing on the order of 100GB of logs per day.
    That's us! But that's only with DEBUG turned up to 11. The nice part, and one of the beauties of tools like log4j, is that we were able to easily add a web page to our application that let's us turn the debugging on and off on the production servers at will. If someone reports a problem, we can turn on the select bits, duplicate the scenario (ideally), and then just turn it back off again. It works wonders for us. But, if you leave it on, the logs would simply slag the disk drives in to smoking ruin. It wouldn't be pretty. No sir.
  14. Stack traces[ Go to top ]

    Grokking stack traces is a time honored skill in the Java world. I think folks learn quite a bit from stack traces. Each framework has their own flavor of stack traces, but it really doesn't take much time to figure them out IMHO. At a glance, yes, they're pretty mind boggling because they take your nice 5 line POJO method and dump it in the center of a huge refactored, abstracted, factoried lifecycle Hell. But the beauty is, of course, that the stuff YOU are interested in always starts with "com.stuff.you.care.about" vs "org.huge.framework". I love stack traces. Beat the crap out of (core dumped).