I agree choice is good. And Apache Jakarta is one (if not THE) best of them. JBoss is pretty dang fine too.
Hats off. I also know that the recruiting marketplace tends to focus on core libs. Loads of projects steer clear of jakarta stuff BECAUSE it is free and open source. I guess my point of view is that it does come down to choice. You must look at the core API's and offerings and you must be aware of how they are evolving. I will personally tend to either write my own or go with the sun libs. This is a time problem. Open source teams are bright, motivated and produce tons of code that is often not well documented. They exert presure on the industry, and I think it's great they do so. But I will choose the core libs, simply because the next job is more likely to use the core libs. Log4j will rapidly change from the only offering, to yet another proprietary (yes I know, think recruiting person) lib. IMHO. It's not religion, it's choice! :) Jonathan ---------------------------------------- Message History ---------------------------------------- From: "Cakalic, James" <[EMAIL PROTECTED]> on 28/01/2002 11:04 EST Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> cc: Subject: RE: RES: handling exceptions Hmm. Just because it appears in the JDK doesn't mean that it is a "good thing". The original JSR47 has changed substantially from its original specification due, in no small part, to the efforts of the log4j community. Even so, its current incarnation still pales in comparison to log4j. You might take time to read the criticism of log4j authors and supporters at http://jakarta.apache.org/log4j/docs/srtw.html. The Apache Software Foundation -- you know they host the Jakarta project which includes Struts and log4j, right? -- does not support the JSR. As a user of Struts, imagine for a moment that JDK 1.5 included an MVC implementation similar to Struts but with reduced functionality and limited extension capability. Would you switch just because it was included in the JDK? Aside from functional differences, it is not practical or advisable for everyone to adopt JDK 1.4 as soon as it hits release. For one thing, Sun only releases the JDK for Windows and Solaris platforms. What if you are using Linux? Or AIX? Or HP-UX? Or AS/400? Or any of the other plethora of platforms which Sun does _not_ support? You'll have to wait for vendor implementations which could be months after the JDK release. As developers of application-server based software, most of us are also sensitive to the period of time it takes for the server vendors to support a new JDK. This was rather substantial between 1.2 and 1.3. I'm not optimistic about 1.4. I can't comment on the nested exceptions of 1.4 as I haven't really looked at this. But I would venture that my above comments apply there equally. Part of the benefit of a large and active open source community is that there are multiple solutions to every problem. We are able to evaluate the alternatives and choose a package that most closely meets our needs. Ultimately, one of these solutions may bubble to the top. But that solution won't always show up in the next JDK. And even if it does, that doesn't mean that it then becomes the _only_ solution for the entire community. Choice is a "good thing". Best regards, Jim Cakalic > -----Original Message----- > From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 7:30 AM > To: Struts Users Mailing List > Subject: Re: RES: handling exceptions > > > > Hi, > > JDK1.4 is at final release candidate stage. They include > nested exceptions (including all remote exceptions) and a > logging framework. > Use these, and not any other version (eg log4j), you will be > future proofing your CV and code. > > Jonathan > =================== > For EJB and Struts code generators see: > http://www.faraway.co.uk/tallsoft/lowroad/ > > ---------------------------------------- Message History > ---------------------------------------- > > > From: Chuck Cavaness <[EMAIL PROTECTED]> on > 28/01/2002 08:22 EST > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > cc: > Subject: Re: RES: handling exceptions > > > Unfortunately no because I think it contains some really nice > features for > Struts. This is a commerical product that I'm working on. > However, I have > received permission to discuss the exception framework in the > Struts book > that I'm working on for OReilly right now. Search the mailing > list archives > for the thread "OReilly Struts Book". > > Chuck > > > At 11:02 AM 1/28/2002 -0200, you wrote: > >Thanks. > >I want to know if your framework of handling exception will > be opensource, > >like struts. > > > > > >-----Mensagem original----- > >De: Chuck Cavaness [mailto:[EMAIL PROTECTED]] > >Enviada em: segunda-feira, 28 de janeiro de 2002 10:27 > >Para: Struts Users Mailing List > >Assunto: Re: handling exceptions > > > > > >We've developed a pretty eloborate exception handling framework on my > >current project. We're using EJB on the backend, so > >we must also deal with remote type exceptions. First we catorgize > >exceptions into those that the user can recover from and > those that they > >can't. Sort of like fatal and non-fatal. You also need to > divide exceptions > >into system and application exceptions. System exceptions > are ones like > >remote exception, or maybe some type of datastore exception. > Application > >exceptions for us are ones like required fields were missing > or duplicate > >values for a unique column. In our world, the same exception > framework has > >to work for ERP systems, so it's not just the web container. > > > >Anyway, for those exceptions that the user can recover from > like "required > >fields missing", we catch those type of exceptions, create > an ActionError > >with a message from the bundle specifically for that > exception, and then > >forward back to the input page. This gives the user a chance > to fix the > >problem and resubmit. For the more severe exceptions, we > also catch those > >and forward to a "system-error" type page since there's > probably nothing > >you can do about it anyway. We use an abstract base action > that all of our > >actions extend. We have all of this behavior in the base > action and none of > >the action classes have to worry about catching these exceptions. The > >abstract base action implements the perform and has an > abstract doWork type > >method. The doWork method is wrapped with the try catch blocks. Each > >concreate action class implements the doWork and doesn't > have to worry > >about the try catch. > > > >I hope that gives you some ideas. > > > >chuck > > > >p.s. Regarding your other post about using System.out in your action > >classes; I wouldn't recommend that approach. Use log4j > instead. That way, > >you can shut off the debug logging externally by just editing the > >log4j.properties file. > > > >At 09:50 AM 1/28/2002 -0200, you wrote: > > >Could somebody help me ? > > > > > >I have to many problems with handling exception of the Struts. > > >what do you suggest to handling exception of the > deployment applications? > > > > > >-- > > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > >-- > >To unsubscribe, e-mail: > ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > >-- > >To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
