I think I'm ok with what you proposed at the bottom. Sounds like the right way or at the very least worth trying. The error was simply a mismatch in interface between component wiring (which *might* be another bug, but still investigating). I think you could repro that easily. In using the testing\tomcat env on Windows this error went silently by; no indication what so ever something was wrong, no msg to console, nothing in the logs. Only the webapp was not loaded. Once you have these proposed changes either check them in and ping me or send me the patch and I'll confirm, your choice. Thanks
Jeremy Boynes wrote: > rick rineholt wrote: >> Jeremy Boynes wrote: >> >>> We should not be writing things to stdout/stderr - we should be logging >>> to Tomcat and let it direct the messages where appropriate. >> I'm Ok with this please make it happen and check that >> with a default tomcat config if there is a issue with the sca >> artifacts being loaded users see some error in TC log or console. >> > > I'd like to understand what problem you had and how it trickled up in a > way that meant that didn't hit the console. > > The reason the delay was in there was so that I could read the messages > as they were being thrown up on the console when running the acceptance > tests (as on Linux the tests were starting Tomcat in a new window with > no scroll history). The delay needs to come out, but the messages were > there. > >>> We should also not rewrap unchecked Exceptions in RuntimeException. >>> would hope Tomcat logged unchecked Exceptions from listeners; if it >>> isn't we should log them to its log rather than stderr before >>> rethrowing. >> Same position as before. >> >>> (with a comment that this is to work around its failure to log). >> I have no issues changing this so it works more in >> line with TC. Big +1 one my part. If I knew how to do it I may have >> done it that (right) way in the first place. I'll be watching your >> changes for educational purposes :-) > >> HOWEVER I'm a -1 to any change >> back to what is was before where a user has to spend 4 hours in a >> debugger to figure out why a bad sca.module or any issues loading the >> sca components failed. This needs to be reported by default console >> and/or log etc. Logging is not sufficient for this type of error. >> > > See my comment at the start. Now maybe the way the tests were set up led > to a different output, or perhaps it's different on Windows vs. Linux > (I'm assuming you're running on Windows) but I think we need more info > to reproduce the problem. > > How about this: I make the changes that: > * remove the delay > * log ConfigurationExceptions through Tomcat > * log (unchecked) Tuscany exceptions through Tomcat > * pass other unchecked Exceptions to Tomcat with the expectation that > it will log them; if we find it doesn't we add in the code to log them > > That way any problem should get reported by Tomcat (in its log and on > its console). > > We can then test with the problem that you were seeing and check that > the output goes somewhere. If it does, we're OK; if it doesn't then we > find a different way to get them logged. > > Sound good? > -- > Jeremy > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
