You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2003/06/10 05:46:03 UTC

DO NOT REPLY [Bug 20632] New: - Refactored reflection feature of ToStringBuilder into new ReflectionToStringBuilder

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20632>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20632

Refactored reflection feature of ToStringBuilder into new ReflectionToStringBuilder 

           Summary: Refactored reflection feature of ToStringBuilder into
                    new ReflectionToStringBuilder
           Product: Commons
           Version: Nightly Builds
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Lang
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: ggregory@seagullsw.com


Original email thread from commons-user, read bottom-up.
---
[This perhaps really belongs on the dev list but this thread was started here.]

I have committed a refactoring of ToStringBuilder which creates a new class
called ReflectionToStringBuilder to CVS. It should be in the June 3rd
nightly-build or you can get the latest from CVS. 

Gary

-----Original Message-----
From: Gary Gregory [mailto:ggregory@seagullsw.com] 
Sent: Sunday, June 01, 2003 16:43
To: 'Jakarta Commons Users List'
Subject: RE: ToStringBuilder.reflectionToString() problem

Hello,

Currently, we do not allow:

new ToStringBuilder(null)

We throw an IllegalArgumentException("The object to create a toString for must
not be null");

I am refactoring the reflection toString() code into a ToStringBuilder subclass
in order for people to customize some features themselves. The reflection
toString() does allow null values. Of course, now that I subclass
ToStringBuilder, I get the IllegalArgumentException for null values, a step
backwards.

Therefore, I would like to change the behavior of ToStringBuilder such that:

new ToStringBuilder(null).toString()

returns "null".

Are there any objections to this?

Thanks,
Gary

-----Original Message-----
From: Gary Gregory [mailto:ggregory@seagullsw.com] 
Sent: Tuesday, May 27, 2003 16:12
To: 'Jakarta Commons Users List'
Subject: RE: ToStringBuilder.reflectionToString() problem

Right, this is a good idea that I have considered in the past. The way we
specify whether or not to output transients is a bit bogus IMHO, there is room
in all of this for an object that would let you tweak all of this behavior. I'll
think about this tonight and propose something if I can come up with something
not too nasty.

Gary

-----Original Message-----
From: Tolley Shorn [mailto:Shorn.Tolley@nrm.qld.gov.au] 
Sent: Tuesday, May 27, 2003 16:07
To: Jakarta Commons Users List
Subject: RE: ToStringBuilder.reflectionToString() problem


It's workable, I did it last night in order to keep going.  It just means I
don't get (almost) free toString()s anymore.

What about making the worker methods non-static and overridable instead? Then I
could subclass ToStringBuilder to build in the knowledge. Or factoring out a
worker class that can be plugged in similarly to ToStringStyle? Or some kind of
extension of the mechanism that specifies whether or not to use transients?

Cheers,
Shorn.

> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Wednesday, 28 May 2003 2:37 AM
> To: 'Jakarta Commons Users List'
> Subject: RE: ToStringBuilder.reflectionToString() problem
> 
> 
> Hello,
> 
> The quick answer to your question (without adding features to
> ToStringBuilder) is to use the non-reflection APIs. For example:
> 
>    public String toString() {
>      return new ToStringBuilder(this).
>        append("name", name).
>        append("age", age).
>        append("smoker", smoker).
>        toString();
>    }
> 
> If this is not acceptable, we can discuss how to make your
> feature request
> fit in the ToStringBuilder framework. I am not sure the 
> proposed solution
> fits: (1) It breaks the model-view type of separation b/w the 
> builder and
> the style class and (2) it requires the access to be set on a 
> per field
> basis, which, the current impl is not factored to do.
> 
> So, in a nutshell, is the above example workable for you (or not)? 
> Obviously, using the reflection method is less code.
> 
> Gary
> 
> -----Original Message-----
> From: Tolley Shorn [mailto:Shorn.Tolley@nrm.qld.gov.au]
> Sent: Tuesday, May 27, 2003 02:51
> To: commons-user@jakarta.apache.org
> Subject: ToStringBuilder.reflectionToString() problem
> 
> Hi folks,
> 
> I've got a bit of a problem with the ToStringBuilder's
> reflectionToString
> method.
> I'd like to suggest a very small improvement (I think) to the
> ToStringBuilder interface.
> 
> We're using Hibernate to provide the persistence of our domain model. 
> I would like to use ToStringBuilder to provide accurate
> toString() methods
> for the classes in our domain model.
> Unfortunately, in some circumstances Hibernate uses an OS library call 
> CgLib. CgLib is a pretty nifty little library that dynamically 
> constructs JVM bytecode.
> Hibernate uses CgLib to provide transparent proxies.
> 
> Unfortunately, becuase of the structure of our app (not
> really Hibernate or
> CgLib's fault), the reflectionToString() method will cause an 
> exception
> because it will try to access the CgLib class outside of an 
> appropriate
> scope (becuase we call toString() outside of the appropriate scope).
> 
> Basically, I would like to be able to customize the ToStringBuilder to 
> decide on a per-attribute basis whether or not to access a given field 
> using reflection.
> 
> What I'd like the reflectionToString method to do is to implement the 
> template design pattern by delegating the actual access and formatting 
> of the individual attribute to a method on the ToStringStyle.
> 
> The basic ToStringStyle could just delegate this decision
> straight back to
> the ordinary ToStringBuiler, so for ordinary use the 
> interface wouldn't
> change at all.
> With this functionality you could have all kinds of fun with 
> doing special
> things for certain attribute names or types.
> 
> What this change would allow me to do is something like this:
> 
> class BaseEntity{
> 	public toString(){
> 		return ToStringBuilder.reflectionToString(this, new 
> CgLibAwareToStringStyle());
> 	}
> }
> 
> CgLibAwareToStringStyle extends StandardToStringStyle {
> 	public String appendField(ToStringBuilder builder, Field f){
> 		if(
> f.getType().isAssignableFrom(CgLibMarkerInterface.class)
> ){
> 			// do a special CgLib appropriate thing 
> that won't
> make my app barf :)
> 		}
> 		else {
> 			builder.append(f);
> 		}
> 	}
> }
> 
> Maybe I'm missing a better way of doing this with the current 
> ToStringBuilder interface? At the moment it appears I'll have to 
> duplicate the ToStringBuilder in our
> app and extend it so I can keep going (or forfeit 
> ToStringBuiler's labour
> saving functionality).
> 
> What do you folks think?
> 
> Cheers,
> Shorn.
> 
> 
> **************************************************************
> **********
> The information in this e-mail together with any attachments is 
> intended only for the person or entity to which it is addressed and 
> may contain confidential and/or privileged material.
> 
> Any form of review, disclosure, modification, distribution and/or 
> publication of this e-mail message is prohibited.
> 
> If you have received this message in error, you are asked to inform 
> the sender as quickly as possible and delete this message and any 
> copies of this message from your computer and/or your computer system 
> network.
> **************************************************************
> **********
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


************************************************************************
The information in this e-mail together with any attachments is intended only
for the person or entity to which it is addressed and may contain confidential
and/or privileged material.

Any form of review, disclosure, modification, distribution and/or publication of
this e-mail message is prohibited.  

If you have received this message in error, you are asked to inform the sender
as quickly as possible and delete this message and any copies of this message
from your computer and/or your computer system network.  
************************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org