[LANG-245] Refactored reflection feature of ToStringBuilder into new ReflectionToStringBuilder

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0
• Fix Version/s: 2.0

Environment

Operating System: All
Platform: All

• Bugzilla Id: 20632
• Assignee: Unassigned
• Reporter: Gary D. Gregory
• Created: 10/Jun/03 10:46
• Updated: 10/Mar/11 22:30
• Resolved: 16/May/06 12:39

Description

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 [e-mail]
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 [e-mail]
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 [e-mail]
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 [e-mail]
> 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 [e-mail]
> Sent: Tuesday, May 27, 2003 02:51
> To: [e-mail]
> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>

************************************************************************
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: [e-mail]
For additional commands, e-mail: [e-mail]