Hi, Paul. Just yesterday I wanted to make sure the HttpServletRequest I modified in a filter is the very same instance that arrives at the JSP, as I was wondering why getParameter() would return different results for the JSP.
Having a "System.out.println(request)" in my filter and the same line in the JSP gave me a quick result for debugging. I know the address could have been reused meanwhile by another instance, but that is very unlikely - especially since the reference to the request from the filter remains valid during the run of the JSP. But how could I have done that comparison with ==? Hiran ----------------------------------------- Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 > -----Original Message----- > From: Paul Speed [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 7. Oktober 2004 17:39 > To: Struts Developers List > Subject: Re: Proposed Action base class change > > I'd just like to point out that the only valid way to tell if > two objects are the same instance if to use ==. Any other > approach will not work. > > Comparing the toString() method results as you do is only > really comparing the hashcodes... which are not unique by a > long shot (I never assume people know this). Besides, == is > even faster. What cases do you find that you've had to use > .toString().equals(...) where you couldn't just do an == check? > > -Paul > > [EMAIL PROTECTED] wrote: > > > Hi, Frank. > > > > I do not agree. While in most cases it is desireable to see > inside a bean (hence I created my > > public static String toString(Object bean) method), > there are times > > when I just have to make sure a bean is not just equal but > the same instance. > > The java.lang.Object.toString() methods allows me to that > quite quickly as the memory address is printed. > > > > Unless you have another way to provide that information, > I'd rather stick with the default toString() plus some > utility toString(Object) method. The impact for you is not > too much. What you code so far is: > > log.debug("mybean="+mybean); > > and you'd have to change that to > > log.debug("mybean="+BeanUtil.toString(mybean)); > > which will allow you to either see the memory address or > the contents, whatever you prefer. > > > > Hiran > > > > ----------------------------------------- > > Hiran Chaudhuri > > SAG Systemhaus GmbH > > Elsenheimer Straße 11 > > 80867 München > > Phone +49-89-54 74 21 34 > > Fax +49-89-54 74 21 99 > > > > > > > > > > > >>-----Original Message----- > >>From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > >>Sent: Donnerstag, 7. Oktober 2004 13:43 > >>To: Struts Developers List > >>Subject: Re: Proposed Action base class change > >> > >>Hi Niall, > >> > >>I certainly agree it would not be possible to satisfy everyone, but > >>seeing as the intrinsic toString() is all but useless (and > people do > >>generally expect that to be the case with many classes), > why not give > >>an implementation that is of at least some use to some > people? Surely > >>it would be better than what you get now? Obviously it's something > >>many people will override, and that's of course the whole point of > >>inheritance. But providing even a slightly more useful default > >>implementation (and maybe telling people it's a basic default > >>implementation so as to try and keep the flood of bugzilla > requests to > >>a > >>minimum) seems to me like a good idea. > >> > >>I can't address your point about dynabeans because I > haven't used them > >>enough to be able to intelligently comment (which is to say > I haven't > >>used them at all! :) )... I wouodn't imagine some basic > implementation > >>would be too tough for them as well. > >> > >>In any case, I will look at the toString builders you mentioned... > >>I've come to really like using the commons packages and I try to > >>whenever I can. This would be a good case I think, if it > doesn't get > >>added as I proposed. I already have an ActionHelpers class with a > >>bunch of similarly-themed static methods for use from Actions, so > >>maybe it's time to do so for forms as well. > >> > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >> > >>Niall Pemberton wrote: > >> > >>>Frank, > >>> > >>>For me it wouldn't be any use unless it also handled > >> > >>DynaBeans. Even > >> > >>>then I'd end up overriding it because I have some formatting utils > >>>which do dates, arrays and collections. Seems to me if we > put it in > >>>then we would end up with a monster trying to satisy > >> > >>everyones needs > >> > >>>and forever dealing with bugzilla requests for enhacements > (someone > >>>would want an i18n version!) - all just for debugging. > >>> > >>>The easiest thing is to just put all that code into a > >> > >>utility method - > >> > >>>that way its only a one liner in the toString() - even > >> > >>better if you > >> > >>>have your own "base" ActionForm that all you others derive > >> > >>from, then > >> > >>>its only in one place. > >>> > >>>Also, there are a set of "toString" builders in commons > >> > >>lang which you > >> > >>>might like to use - including a reflection one like yours: > >>> > >>> > >> > >>http://jakarta.apache.org/commons/lang/api/org/apache/common > s/lang/bui > >> > >>>lder/package-summary.html > >>> > >> > >>http://jakarta.apache.org/commons/lang/api/org/apache/common > s/lang/bui > >> > >>>lder/ReflectionToStringBuilder.html > >>> > >>>Niall > >>> > >>>----- Original Message ----- > >>>From: "Frank W. Zammetti" <[EMAIL PROTECTED]> > >>>To: "Struts Developer" <[EMAIL PROTECTED]> > >>>Sent: Thursday, October 07, 2004 4:29 AM > >>>Subject: Re: Proposed Action base class change > >>> > >>> > >>> > >>> > >>>>Obviously I made a typo in the subject... this applies to the > >>>>ActionForm base class. > >>>> > >>>>Did anyone have any comment on this? I've noticed a lack > >> > >>of activity > >> > >>>>on the list lately... > >>>> > >>>> > >>>> > >>>>>Hello all... > >>>>> > >>>>>I find myself all the time overloading toString() of my > >> > >>ActionForms > >> > >>>>>for > >>> > >>>debugging > >>> > >>> > >>>>>purposes, so I can easily dump the current state of the > object. I > >>>>>had > >>> > >>>been doing > >>> > >>> > >>>>>this for each ActionForm class, specifically for it, but > >> > >>it ocurrs to > >> > >>>>>me > >>> > >>>that a > >>> > >>> > >>>>>general-purpose reflection-based approach would be better. > >>>>> > >>>>>I'd like to propose adding this functionality to the > >> > >>ActionForm base > >> > >>>class. Here's > >>> > >>> > >>>>>the code I propose adding: > >>>>> > >>>>>import java.lang.reflect.Field; > >>>>>public static final AVERAGE_FIELD_SIZE = 25; public String > >> > >>toString() > >> > >>>>>{ > >>>>> String str = ""; > >>>>> StringBuffer sb = null; > >>>>> try { > >>>>> Field[] fields = this.getClass().getDeclaredFields(); > >>>>> sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE); > >>>>> for (int i = 0; i < fields.length; i++) { > >>>>> if (sb.length() > 0) { sb.append(", "); } > >>>>> sb.append(fields[i].getName() + "=" + fields[i].get(this)); > >>>>> } > >>>>> str = sb.toString().trim(); > >>>>> } catch (Exception e) { > >>>>> str = "Exception in ActionForm.toString() : " + e; } return > >>>>>str; } > >>>>> > >>>>>The value of AVERAGE_FIELD_SIZE is a matter of debate, > and it's of > >>> > >>>course impossible > >>> > >>> > >>>>>to come up with a real value, so something reasonable is > >> > >>the answer. > >> > >>>>>25 > >>> > >>>struck me > >>> > >>> > >>>>>as a decent starting point. > >>>>> > >>>>>What does everyone think? I find this functionality to be very > >>>>>useful > >>> > >>>in my work, > >>> > >>> > >>>>>and I suspect others may as well. The code doesn't add any > >>>>>dependencies > >>> > >>>outside > >>> > >>> > >>>>>J2SE, and it's certainly simple enough as to not be > >> > >>particularly risky. > >> > >>>>>Thanks all! > >>>>> > >>>>>Frank W. Zammetti > >>>>>Founder and Chief Software Architect Omnytex Technologies > >>>>>http://www.omnytex.com > >>>>> > >>>> > >>>> > >>>>------------------------------------------------------------ > >> > >>--------- > >> > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] For > >>>>additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>------------------------------------------------------------ > --------- > >> > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] For > >>>additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] For > >>additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
