morph-user — For users of the Morph framework. Please post questions here.

[morph-user] Collections and cyclic dependencies

[Matthieu R. <mat...@gm...>]

Hi,

First, congratulation for building Morph, it looks very nice.

I'd like to use morph for my current project and would need the
features you mentioned in previous mails: untyped collection and
circular dependencies. Actually I don't have any "stricto sensu"
circular dependencies right now but I have bidirectional
relationships, I guess it's just the same from Morph's standpoint,
right?

So if you can plan a release this week-end that would be just fine for
me as well. No need to rush, I just started integrating Morph and I
can wait a bit.

Once again, thank a lot for your nice job,

Matthieu Riou.

Re: [morph-user] How do I convert a Collection of objects?

[Hernan S. <hsi...@pd...>]

On Wed, 2 Mar 2005, Matt Sgarlata wrote:

> Hi Hernan, I'm glad you've found the package useful!

Sure, thanks for the quick response!

> If your destination ParentDTO exposes its children property as a 
> ChildDTO[] array, I think Morph should detect that a conversion is 
> necessary.  If you want to do the conversion to an untyped collection 
> (e.g. - a List of ChildDTO), then you'll have to wait until the next 
> release :)  I've actually already written the code that does this, I 
> just haven't polished it into a release yet.  Can you use an array, or 
> would you like me to do another release for you?

I can use an array, but do I need to write a new Converter to go from ChildDO[] 
to ChildDTO[], or can I leverage the Converter I already have for going from 
ChildDO to ChildDTO?

Ultimately, I do want to be able to transform any graph to any other graph 
including the untyped collections.  The source graph in my case is a Domain 
Object Model which is persisted using Hibernate... so it heavily uses java.util 
Collections to define relations.

> This past couple weeks I finally had a chance to use Morph with one of 
> my own projects (we have an object graph generated by Hibernate that 
> needs to be serialized and sent to a remote client using Hessian).  To 
> accomplish this, I made all the necessary changes to allow cyclic graphs 
> to be converted and to allow for more advanced collection 
> transformations like the type you mention, Hernan.  I was aiming to do a 
> release this weekend, but if anyone needs it sooner, I can certainly do 
> my best to do a new release tomorrow.

I don't want to hurry you like that, I'm still only beginning to use the 
framework so there's no rush.

thanks again...
Hernan


> Hernan Silberman wrote:
> 
> >Firstly, thanks for building Morph, I can tell it's going to save me tons of 
> >time and many other people too.
> >
> >I'm just starting out with Morph and I have a simple question.  I have a 
> >DelegatingTransformer configured in my code that knows all about the custom 
> >transformers I've built.
> >
> >Now I'm building a new Transformer for a class ParentDO that has a collection of 
> >ChildDO instances and a simple accessor method:
> >
> >public Collection getChildren();
> >
> >How do I tell Morph to convert all of the ChildDO objects in 
> >someParent.getChildren() to some other type (ChildDTO)?
> >
> >Being overly simplistic about things, I'm looking for a method like this:
> >Collection Morph.convert( DestinationDTO.class, Collection );
> >
> >Any help is much appreciated.
> >
> >thanks...
> >hernan

Re: [morph-user] How do I convert a Collection of objects?

[Matt S. <sga...@us...>]

Hi Hernan, I'm glad you've found the package useful!

If your destination ParentDTO exposes its children property as a 
ChildDTO[] array, I think Morph should detect that a conversion is 
necessary.  If you want to do the conversion to an untyped collection 
(e.g. - a List of ChildDTO), then you'll have to wait until the next 
release :)  I've actually already written the code that does this, I 
just haven't polished it into a release yet.  Can you use an array, or 
would you like me to do another release for you?

This past couple weeks I finally had a chance to use Morph with one of 
my own projects (we have an object graph generated by Hibernate that 
needs to be serialized and sent to a remote client using Hessian).  To 
accomplish this, I made all the necessary changes to allow cyclic graphs 
to be converted and to allow for more advanced collection 
transformations like the type you mention, Hernan.  I was aiming to do a 
release this weekend, but if anyone needs it sooner, I can certainly do 
my best to do a new release tomorrow.

Matt

Hernan Silberman wrote:

>Firstly, thanks for building Morph, I can tell it's going to save me tons of 
>time and many other people too.
>
>I'm just starting out with Morph and I have a simple question.  I have a 
>DelegatingTransformer configured in my code that knows all about the custom 
>transformers I've built.
>
>Now I'm building a new Transformer for a class ParentDO that has a collection of 
>ChildDO instances and a simple accessor method:
>
>public Collection getChildren();
>
>How do I tell Morph to convert all of the ChildDO objects in 
>someParent.getChildren() to some other type (ChildDTO)?
>
>Being overly simplistic about things, I'm looking for a method like this:
>Collection Morph.convert( DestinationDTO.class, Collection );
>
>Any help is much appreciated.
>
>thanks...
>hernan
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>  
>

[morph-user] How do I convert a Collection of objects?

[Hernan S. <hsi...@pd...>]

Firstly, thanks for building Morph, I can tell it's going to save me tons of 
time and many other people too.

I'm just starting out with Morph and I have a simple question.  I have a 
DelegatingTransformer configured in my code that knows all about the custom 
transformers I've built.

Now I'm building a new Transformer for a class ParentDO that has a collection of 
ChildDO instances and a simple accessor method:

public Collection getChildren();

How do I tell Morph to convert all of the ChildDO objects in 
someParent.getChildren() to some other type (ChildDTO)?

Being overly simplistic about things, I'm looking for a method like this:
Collection Morph.convert( DestinationDTO.class, Collection );

Any help is much appreciated.

thanks...
hernan

[morph-user] Using Morph in the real world

[Matt S. <sga...@us...>]

This weekend I did some work for the startup company I work for, Spider 
Strategies, and it required me to use Morph!  It's very exciting for me 
to finally have some real work to do with the Morph framework, because 
up until now it's been mostly me working out ideas rather than solving 
actual problems.  The problem I ran into at work is converting an object 
graph retrieved from a database with Hibernate to an object graph that 
can be serialized to a remote client using the Hessian binary web 
services protocol.  I'm still not done, but I ran into a usability issue 
that I think will result in me making some changes to Morph coming up:
* The DelegatingTransformer is a bit difficult to customize if I want to 
use the default behavior but just replace a converter or two.  I'm 
thinking that the delegates property of the transformer should be 
changed from a List to a Map that will use some type of a 
LinkedHashMap-type implementation, as Alex recommended for the 
PropertyNameMatchingCopier and PropertyNameMappingCopier
* When you customize a DelegatingTransformer with delegates, those 
delegates that have to do nested transformations (ContainerCopier, 
PropertyNameMatchingCopier, etc) don't use their parent transformer for 
their nested transformations.  This is extremely counter-intuitive.  I 
think I'll introduce a new NestedTransformer interface that, if 
implemented, will cause DelegatingTransformer to specify itself as the 
nested transformer when new delegates are registered with it.

Here are some other changes that are coming up:
* Working on a new String representation of an Object graph for Morph's 
logs and for general debugging
* Introduced a new CloningIdentityConverter that assists with cloning an 
object graph
* I'm starting to turn on Morph's logging to do debugging, so the 
quality of Morph's log should start to improve

Matt

[morph-user] Re: [morph-developer] FW: Some ideas for the current Morph release

[Matt S. <sga...@us...>]

Hi Alex,

Point taking with maintaining the order of properties specified in the=20
mapping (if an OrderedMap implementation is used).  I'll modify the=20
BiDirectionalMap to maintain the ordering, and I'll be more careful not=20
to just do new HashMap(map) if I need a new instance of a Map :)  It=20
sounds like we'll need some type of OrderedMap implementation to=20
implement BiDirectionalMap, so I may copy one from commons-lang.  I=20
don't want to introduce a new dependency on commons-lang, because right=20
now Morph only requires commons-logging.  I'm not going to make all=20
these changes quite yet, because I'm still thinking about the=20
PropertyNameMappingCopier.  It's tickling the back of my mind that there =

must be a case where making the PNMC bidirectional will lead to=20
undesired behavior, but I haven't thought it through enough to determine =

the exact cast and figure out a fix.

Interesting idea regarding using URN notiation with nested property=20
names.  Right now how it works is if you specify a "class" property=20
yourself, that one takes precedence over the implicit property.  I kind=20
of like that approach because it keeps the property names simple.  If a=20
user wants to access the implicit property, then she might want to=20
consider not overwriting it :)  It's also a kind of sneaky way of=20
discouraging the use of "class" as a property name.  Objects can't have=20
a property with that name already, so you probably should avoid it when=20
dealing with Maps, etc.

Excellent idea to have the ObjectReflector detect addPropertyName=20
methods.  I definitely would like to see this functionality added to=20
Morph :)  If you'd like to contribute it, all the better!  In terms of=20
my TODO list, I transferred all of it to the issue tracker on=20
SourceForge.  Feel free to tackle anything that interests you!  Items=20
that show up grey are items I consider low-priority, and I would prefer=20
to push to a Morph 1.1 release.  However, anything you implement will=20
certainly be in the next release :)

I think this conversation probably makes sense to continue on the=20
morph-developer's list anyway, since morph-user is bouncing for you.

Matt

Volanis, Alexander wrote:

>This is bouncing from the morph-user list today. I am forwarding to you =
directly as well as the dev list.=20
>
>-----Original Message-----
>From: Volanis, Alexander=20
>Sent: Wednesday, February 16, 2005 1:18 PM
>To: 'mor...@li...'
>Subject: FW: Some ideas for the current Morph release
>
>Hi Matt,
>
>I really like where you are going with this release. The new features wo=
rk well and collapsing the SelectivePropertyNameMatchingCopier into the P=
ropertyNameMatchingCopier does seem like the right thing to do.
>
>Looking at the changes that you are in the process of making in Property=
NameMappingCopier I have one observation to make. I have used an OrderedM=
ap as input to the setMapping() method to control the order of property c=
opying. In some specialized cases the order in which properties are copie=
d from one object to another is significant. Here is for example my reaso=
n for specifying the order. One of the objects I had to copy contained co=
llections of beans that had ID properties. Within the rest of the object =
there were other objects that made references to the aforementioned beans=
=2E The references were plain object references that were established dur=
ing the construction of the source object by reading an XML file that con=
tained IDREFs. As I transformed the source objects I had to maintain the =
same references where applicable. My solution was to make an abstract con=
verter class that all my copiers were derived from and look for the ID pr=
operty present on any destination object. If there was one I collected th=
e ID and the object reference in a Map. As the transformation progressed =
I would encounter the objects that needed to resolve the references to th=
e new transformed objects. At that time I would get the required object r=
eferences from my previously polulated Map and set them in my new referen=
cing objects. This was only possible if the order of copying was strictly=
 controlled by my mapping specifications.
>
>I believe there is a need to provide an OrderedHashMap implementation to=
 support this functionality. The JDK 1.4 LinkedHashMap provides this func=
tionality for me. You should probably consider using this in your BiDirec=
tionalMap implementation as well. It may make sense to replace all Maps w=
ith something like that were there is a chance that a mapping order has t=
o be preseved. At least there should be some way to specify that iteratio=
n order is significant and has to be maintained. In some cases it seems e=
asy to just create a new plain HashMap from the one specified as input bu=
t if you do this the iteration order cannot be preserved. I find at least=
 a couple of SF.NET projects that already provide this type of Map. Casto=
r also has an OrderedHashMap to maintain JDK 1.2 and 1.3 compatibility. I=
 also know Jacarta commons has a SequencedHashMap that works. It may be p=
ossible to use a fa=E7ade that can expose the best available HashMap impl=
ementation instead.
>
>Another comment has to do with the "implicit properties". Using URI nota=
tion you could replace the string for the IMPLICIT_PROPERTY_CLASS with "u=
rn:morph:properties:class" instead of just "class". This will guarantee t=
hat there will be no collisions with existing bean properties.
>
>Finally one more observation. I think the ReflectionInfo class should al=
so look for methods of the form addPropertyName(ObjectType arg) and addPr=
opertyName(int index, ObjectType arg). These are common in cases of colle=
ction properties that are managed as arrays. Castor objects are full of t=
hese and to work with them I had to enable the Castor extra collection me=
thods that give access to the underlying collection by reference. The rea=
son I had to do this was that arrays (which is what I get otherwise) do n=
ot have a GrowableContainerReflector and cannot have elements added if th=
ey are not already sized to the necessary dimensions. If the ReflectionIn=
fo can detect the presense of addPropertyName methods we can handle array=
s as if they have a GrowableContainerReflector. In addition to getting th=
e arrays to grow as needed it provides type checking that I lost when I h=
ad to use the Castor collection references.
>
>I may do some work on this last topic myself if I have some free time (w=
hich has been severely limited lately). Let me know if there is anything =
that I can pick up from your TODO list.
>
>Alex
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.=

>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>_______________________________________________
>morph-developer mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-developer
>
> =20
>

[morph-user] Morph 0.8.2 Released

[Matt S. <mat...@ve...>]

Morph 0.8.2 is available for download.  This release includes 
enhancements, bug fixes and a new reference document.  Many thanks to 
Alexander Volanis for his contributions to this release!

New in this release:

    * Improvements to ObjectReflector that bring it more in line with
      the JavaBeans specification. Thanks to Alexander Volanis!
    * Major improvements to the PropertyNameMatchingCopier and
      PropertyNameMappingCopier. The capabilities of the
      SelectivePropertyNameMatchingCopier have been folded into the
      PropertyNameMatchingCopier. Again, thanks to Alexander Volanis!
    * Began a reference document <cid:par...@ve...>
    * Renamed "pseudo properties" for Sizable and Bean objects to
      "implicit properties".
    * Updated the wrapper package so that it throws WrapperExceptions
      rather than ReflectionExceptions
    * Changed the behavior of the BeanReflector.getPropertyNames method
      so that it no longer returns the implicit properties for the
      object, unless those properties have been explicitly defined in
      the object.


Matt

Re: [morph-user] Re: Where to start?

[Matt S. <mat...@ve...>]

Hi Chris,

Thanks for your interest in Morph!  I haven't had a chance to write much 
in the way of a user's guide yet, but I have gotten started.  I'll be 
putting together a more detailed user's guide this weekend, so I'll 
focus to start on going over how to do transformations, and I can even 
include in the examples the exact types of conversions you're trying to 
perform :)  Can you give me some more details about exactly what it is 
you're trying to do?  Are you trying to convert a String property of a 
LazyDynaBean into a List<BusinessObject>?

For now, I attached what I have so far in terms of a user's guide.

Matt

chris wrote:

>Follow-up.. I just realized I probably wasn't very clear.  
>I just saw this comment on the the homepage, and realized that's one
>thing I would like to do if possible.
>(in both directions.. something like  com.package.A[] <->
>java.util.List<com.package.B>)
>
>>From the homepage...
>"Will Morph work smoothly with JDK 1.5 once we are ready to build in
>that support? For example, will the way Morph is currently structured
>allow conversions like java.lang.String[] ->
>java.util.List<java.lang.String>?"
>
>Basically I have an object graph complete with nested objects,
>collections, etc.  I am using JDK 1.5 and ideally if I made made the
>collections typesafe, then Morph would utilize that to determine the
>types of objects to instantiate during the conversion (from all
>strings in my lazydynabeans to my 'business' classes).  However, this
>is not a major requirement... if Morph requires that I tell it which
>types to use for the various collections, then that's OK.. I just
>don't know how.
>
>Thanks
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>  
>

[morph-user] Re: Where to start?

[chris <one...@gm...>]

Follow-up.. I just realized I probably wasn't very clear.  
I just saw this comment on the the homepage, and realized that's one
thing I would like to do if possible.
(in both directions.. something like  com.package.A[] <->
java.util.List<com.package.B>)

From the homepage...
"Will Morph work smoothly with JDK 1.5 once we are ready to build in
that support? For example, will the way Morph is currently structured
allow conversions like java.lang.String[] ->
java.util.List<java.lang.String>?"

Basically I have an object graph complete with nested objects,
collections, etc.  I am using JDK 1.5 and ideally if I made made the
collections typesafe, then Morph would utilize that to determine the
types of objects to instantiate during the conversion (from all
strings in my lazydynabeans to my 'business' classes).  However, this
is not a major requirement... if Morph requires that I tell it which
types to use for the various collections, then that's OK.. I just
don't know how.

Thanks

[morph-user] Where to start?

[chris <one...@gm...>]

Hi,
I was looking for an alternative to BeanUtils and came across your
project.  It looks good so far.  Is there no sample code (for users)
available.. i dont' see it on the web site?
More specifically, I'm wanting to convert to and from nested/indexed
lazydynabeans.  I see that there's good javadoc, but I could use a
better starting point.  Any pointers?  Thanks!

Re: [morph-user] Re: Re: Contribution to Morph

[Matt S. <sga...@us...>]

OK, I see how you have things setup.  Do you think, had the 
PropertyNameMatching and PropertyNameMapping copiers been available with 
transformations built in, that you could have avoided subclassing the 
ObjectReflector?  I was hoping to keep transformations completely 
outside reflectors and squarely in transformers.  I think in the long 
term this will make using Morph easier to understand because we can keep 
our message simple: Reflectors are for retrieving information from 
objects.  Transformers are for doing transformations.

When you say you created a variety of ContainerCopiers, you mean you 
created new instances of ContainerCopiers, just configured them 
differently?  I hope so... my goal was to avoid having to subclass the 
ContainerCopier :)

Very good point with divide and conquer.  Could you elaborate what you 
mean in terms of attempting to transform too many types at once?  I 
think both of these will be great information to include in the user's 
guide.

Any example would be much appreciated.  The simpler the example, the 
easier it will be to understand.  We can always add a more complex 
example later :)

Matt

PS - if you're ever having trouble with Morph and you think it's a bug, 
feel free to post your error to this list.  I will be more than happy to 
look into the error quickly and provide a fix for you.

Volanis, Alexander wrote:

>Hi Matt,
>
>Thanks for adding me to the authors listings. I actually solved the type
>conversion problem in a different way. I subclassed your ObjectReflector
>and added a transformation process akin to what the ContainerCopier
>does, in addition I made this reflector process collections in a special
>way to handle collection transformations. Then I prepared a
>DelegatingConverter with a variety of ContainerCopiers suitable for any
>collections I was processing. Finally I set the DelegatingConverter in
>the transformer property of my ObjectConverter and set the
>ObjectConverter as the reflector property of the top level property
>copier I was using. As the property copier copied each property the
>transformations were applied to it as needed.
>
>The end result was a cascading effect of copiers invoking transformers
>which invoked other copiers as the tree was traversed. The setup of the
>relationships of the copiers and transformers was done with static
>initializers since all relationships are static. So, the first
>invocation of the root copier instantiated all delegates at once and the
>copy process proceeded quickly. Aside from a slight delay that is
>obvious the very first time the copy is performed, the processing was
>very effective and fast on subsequent passes.
>
>The point was to use a divide and conquer type of strategy. Each copier
>at each level of the tree understands how to copy the remaining subtree.
>It is easy to explain and maintain as each copier has a specific set of
>transformations and objects to deal with. I found that it is best to
>avoid trying to transform too many different types at once as it can
>become confusing and error prone because some transformations introduce
>abiguity.
>
>I cannot promise a very elaborate example but I'll do my best to
>illustrate the concepts.
>
>Thanks,
>Alex
>
>Date: Tue, 08 Feb 2005 00:46:28 -0500
>From: Matt Sgarlata <sga...@us...>
>To:  mor...@li...
>Subject: Re: [morph-user] Re: Contribution to Morph
>Reply-To: mor...@li...
>
>Hello again Alex,
>
>Once again, thanks for your contributions!  I'm planning on listing you
>as the secondary @author for TimeToNumberConverter,
>NumberToTimeConverter, ObjectReflector, PropertyNameMatchingCopier,
>PropertyNameMappingCopier, MethodHolder and ReflectionInfo (I broke out
>the later two as their own top-level classes in the reflect.support
>package).
>
>I'm still working on the property name copiers and adding all your other
>changes into Morph, but I should be able to wrap that up soon.  One
>thing I realized as I was looking at the property name copiers is that
>they don't have automatic type conversion in there yet.  When you were
>mapping properties from one object to the other, did you have to do any
>type conversions?  If so, were you doing them manually, using the
>Converters that come with Morph?  With the versions of the property name
>copiers I'm working on, you'll be able to specify a delegate transformer
>object that will be used to do these conversions automatically.  The
>ContainerCopier actually already supports similar behavior.  This allows
>you to, for example, convert a List of Maps into a Person[] array
>automatically (assuming the property names in the Maps match the
>property names in the Person objects).
>
>Still, I'm sure if you could put together an example of converting one
>object graph to another that it would be useful!  Even if you were
>manually using transformers for each step in the process, that might be
>a nice introduction to what Morph is doing behind-the-scenes, before
>showing that you can just do
>MyCustomConverter.convert(TransformedGraphRoot.class,
>notTransformedObjectGraphRoot, locale) once you have things setup.  I'm
>thinking the best place to put the examples will be in the reference
>document.  It's new and not yet directly available on the homepage, but
>the beginnings of it are in CVS.  We can always link from the homepage
>to the HTML version of the reference document if we think such a link is
>worthwhile.  You can provide the examples in any format you like, but if
>you'd like to add directly to the reference document, let me know.  It's
>in XML format so I'll have to write up some brief documentation on how
>to contribute to it.
>
>Matt
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>  
>

[morph-user] Re: Re: Contribution to Morph

[Volanis, A. <AVo...@rs...>]

Hi Matt,

Thanks for adding me to the authors listings. I actually solved the type
conversion problem in a different way. I subclassed your ObjectReflector
and added a transformation process akin to what the ContainerCopier
does, in addition I made this reflector process collections in a special
way to handle collection transformations. Then I prepared a
DelegatingConverter with a variety of ContainerCopiers suitable for any
collections I was processing. Finally I set the DelegatingConverter in
the transformer property of my ObjectConverter and set the
ObjectConverter as the reflector property of the top level property
copier I was using. As the property copier copied each property the
transformations were applied to it as needed.

The end result was a cascading effect of copiers invoking transformers
which invoked other copiers as the tree was traversed. The setup of the
relationships of the copiers and transformers was done with static
initializers since all relationships are static. So, the first
invocation of the root copier instantiated all delegates at once and the
copy process proceeded quickly. Aside from a slight delay that is
obvious the very first time the copy is performed, the processing was
very effective and fast on subsequent passes.

The point was to use a divide and conquer type of strategy. Each copier
at each level of the tree understands how to copy the remaining subtree.
It is easy to explain and maintain as each copier has a specific set of
transformations and objects to deal with. I found that it is best to
avoid trying to transform too many different types at once as it can
become confusing and error prone because some transformations introduce
abiguity.

I cannot promise a very elaborate example but I'll do my best to
illustrate the concepts.

Thanks,
Alex

Date: Tue, 08 Feb 2005 00:46:28 -0500
From: Matt Sgarlata <sga...@us...>
To:  mor...@li...
Subject: Re: [morph-user] Re: Contribution to Morph
Reply-To: mor...@li...

Hello again Alex,

Once again, thanks for your contributions!  I'm planning on listing you
as the secondary @author for TimeToNumberConverter,
NumberToTimeConverter, ObjectReflector, PropertyNameMatchingCopier,
PropertyNameMappingCopier, MethodHolder and ReflectionInfo (I broke out
the later two as their own top-level classes in the reflect.support
package).

I'm still working on the property name copiers and adding all your other
changes into Morph, but I should be able to wrap that up soon.  One
thing I realized as I was looking at the property name copiers is that
they don't have automatic type conversion in there yet.  When you were
mapping properties from one object to the other, did you have to do any
type conversions?  If so, were you doing them manually, using the
Converters that come with Morph?  With the versions of the property name
copiers I'm working on, you'll be able to specify a delegate transformer
object that will be used to do these conversions automatically.  The
ContainerCopier actually already supports similar behavior.  This allows
you to, for example, convert a List of Maps into a Person[] array
automatically (assuming the property names in the Maps match the
property names in the Person objects).

Still, I'm sure if you could put together an example of converting one
object graph to another that it would be useful!  Even if you were
manually using transformers for each step in the process, that might be
a nice introduction to what Morph is doing behind-the-scenes, before
showing that you can just do
MyCustomConverter.convert(TransformedGraphRoot.class,
notTransformedObjectGraphRoot, locale) once you have things setup.  I'm
thinking the best place to put the examples will be in the reference
document.  It's new and not yet directly available on the homepage, but
the beginnings of it are in CVS.  We can always link from the homepage
to the HTML version of the reference document if we think such a link is
worthwhile.  You can provide the examples in any format you like, but if
you'd like to add directly to the reference document, let me know.  It's
in XML format so I'll have to write up some brief documentation on how
to contribute to it.

Matt

Re: [morph-user] Re: Contribution to Morph

[Matt S. <sga...@us...>]

Hello again Alex,

Once again, thanks for your contributions!  I'm planning on listing you 
as the secondary @author for TimeToNumberConverter, 
NumberToTimeConverter, ObjectReflector, PropertyNameMatchingCopier, 
PropertyNameMappingCopier, MethodHolder and ReflectionInfo (I broke out 
the later two as their own top-level classes in the reflect.support 
package).

I'm still working on the property name copiers and adding all your other 
changes into Morph, but I should be able to wrap that up soon.  One 
thing I realized as I was looking at the property name copiers is that 
they don't have automatic type conversion in there yet.  When you were 
mapping properties from one object to the other, did you have to do any 
type conversions?  If so, were you doing them manually, using the 
Converters that come with Morph?  With the versions of the property name 
copiers I'm working on, you'll be able to specify a delegate transformer 
object that will be used to do these conversions automatically.  The 
ContainerCopier actually already supports similar behavior.  This allows 
you to, for example, convert a List of Maps into a Person[] array 
automatically (assuming the property names in the Maps match the 
property names in the Person objects).

Still, I'm sure if you could put together an example of converting one 
object graph to another that it would be useful!  Even if you were 
manually using transformers for each step in the process, that might be 
a nice introduction to what Morph is doing behind-the-scenes, before 
showing that you can just do 
MyCustomConverter.convert(TransformedGraphRoot.class, 
notTransformedObjectGraphRoot, locale) once you have things setup.  I'm 
thinking the best place to put the examples will be in the reference 
document.  It's new and not yet directly available on the homepage, but 
the beginnings of it are in CVS.  We can always link from the homepage 
to the HTML version of the reference document if we think such a link is 
worthwhile.  You can provide the examples in any format you like, but if 
you'd like to add directly to the reference document, let me know.  It's 
in XML format so I'll have to write up some brief documentation on how 
to contribute to it.

Matt

Volanis, Alexander wrote:

>Hi Matt,
>
>Yes, I agree that errorOnMissingProperty is better and true by default
>would make it much more useful. I have been setting it to true always
>because the project I used this in involves many transformations that
>are still evolving and it is easier if the transformers catch my
>fat-fingering for me ;-)
>
>I think PropertyNameMatchingCopier could really be derived by
>SelectivePropertyNameMatchingCopier if you have the copyImpl invoke
>setPropertiesToCopy and the execute super.copyImpl().
>
>I believe the Castor library used exactly this definition of JavaBean
>Collection access. I had coded an arrayMutator/arrayAccessor as well at
>first but desided against it as it did not seem to add anything above
>the normal mutator/accessor options.
>
>If I find the time (which does not seem likely at this instant) I may
>put together an example of how I coded the tree graph conversion. It
>should be an interesting way to show the power of Morph.
>
>Thanks again,
>Alex
>
>Date: Tue, 01 Feb 2005 00:30:29 -0500
>From: Matt Sgarlata <sga...@us...>
>To:  mor...@li...
>Subject: Re: [morph-user] Contribution to Morph
>Reply-To: mor...@li...
>
>Hi Alex,
>
>I'm glad you found Morph useful, and thank you for your contributions!
>
>Quite right, it looks like PropertyNameMappingCopier slipped through the
>cracks.  Thanks for the corrected implementation.  What would you think
>of changing the strict property's name to errorOnMissingProperty?  That
>is a little verbose, but I think also more descriptive.  I agree with
>you, if you went to all the trouble of defining the mapping you probably
>do want it to fail if a property name is missing.  I think we should we
>go ahead and set strict or errorOnMissingProperty to true as the
>default... what do you think?  I like how you used the Map's iterator to
>impose ordering.  I'll definitely add that to the JavaDoc for the class.
>
>I like your changes to the SelectivePropertyNameMatchingCopier.  I think
>we should set the strict or errorOnMissingProperty option to true by
>default for this class as well.  Also, looking back at my TODO that says
>"PropertyNameMatchingCopier should extend this class, not vice-versa", I
>think I changed my mind.  I like the hierarchy as it is.
>
>You're right, if you define a mapping between property names, you
>probably do want it to be bidirection.  Logically, what you're doing is
>specifying an equivalence relation between two different types, so
>normally the relation will be bidirectional.  I think we should remove
>the option of making the PropertyNameMappingCopier unidirectional
>entirely.  If someone wants to define a different mapping for the
>different transformation directions, that person can just use two
>different PropertyNameMappingCopiers.
>
>Thanks for the fixes to NumberToTimeConverter and TimeToNumberConverter!
>
>Actually, I recently found out the JavaBeans specification defines 4
>methods for accessing elements of a JavaBean collection, as listed
>below.  Thanks for taking care of the implementation :) Object[]
>getArray() void setArray(Object[] array) Object getArray(int index) void
>setArray(int index, Object value)
>
>I'll make sure all this gets into the next release of Morph, although it
>has of yet not been scheduled.  I'd like to get better test coverage
>first, perhaps around 70%.  I also want to break out the composite
>package into a separate project.
>
>Matt
>
>Volanis, Alexander wrote:
>
>  
>
>>Hi Matt,
>>
>>I have spent 3 weeks using your excellent Morph package to solve a 
>>deeply nested tree graph conversion. I successfully completed the 
>>"morphing" of a large XML schema processed by Castor objects into 
>>internal project specific Java Bean representations.
>>
>>As a result of this work I came up with a few interesting enhancements 
>>to Morph classes as well as a couple of bug fixes. I am submitting 
>>these classes for your review and possible inclusion into Morph 1.0. I 
>>found the Morph project to be the perfect match for the task at hand 
>>and congratulate you for the excellent work you produced.
>>
>>Without further rambling here is what I have to contribute:
>>
>>The PropertyNameMappingCopier seems to be a simple reincarnation of 
>>PropertyMatchingCopier. Probably a result of coding to fast to meet a 
>>deadline ;-) I attached the corrected implementation with some extra 
>>frills. I discovered it was too easy to fumble the property names and 
>>the copiers would happily skip over the mistyped properties leaving me 
>>wondering what was the problem. To solve this I added a "strict" flag 
>>to the copier that causes a TransformationException to be thrown when a
>>    
>>
>
>  
>
>>specified property fails to copy. If I bothered to specify the property
>>    
>>
>
>  
>
>>chances are I really want to know that it did get copied successfully.
>>Furthermore, the order of copying the mapped properties is dictated by 
>>the Iterator of the Map. Thus if I use an OrderedHashMap I can control 
>>the order for the copy process.
>>
>>Another enhancement was that the order of copying selected properties 
>>in the SelectivePropertyNameMatchingCopier was not set. I reversed the 
>>process by iterating over the properties to copy instead of the 
>>sourceProperties. I also added the strict flag to this one as well.
>>
>>Finally, most of my conversions were bidirectional in the sense I am 
>>converting class X to class Y but I would also want to convert class Y 
>>to class X. This was done at first with a PropertyNameMappingCopier by 
>>specifying the mappings for each direction in the same Map. But it 
>>became obvious that it would be better to make the 
>>PropertyNameMappingCopier handle this. So, the 
>>PropertyNameTwoWayMappingCopier was born. This allows me to have my 
>>strict flag and can copy to/from easily.
>>
>>The TimeToNumberConverter and NumberToTimeConverter gave me trouble at 
>>first until I realized the default assignments for TimeConverter and 
>>NumberConverter were actually wrong. The defaults used 
>>Defaults.CONVERTER instead of Defaults.TIME_CONVERTER and 
>>Defaults.NUMBER_CONVERTER respectively. I changed the assignments of 
>>the defaults to the specific converters and the stack overflow 
>>exceptions I was getting were gone. I noticed version 0.8.1 fixed one 
>>of the two, the other one needs fixing as well.
>>
>>The last problem I encountered was that the Castor classes I was 
>>converting to/from have get/set methods with non-standard arguments.
>>This was causing problems that I resolved by modifying the 
>>ObjectReflector class. When the bean ReflectionInfo is collected I pay 
>>attention to the arguments and use the getter with no arguments and 
>>setter with one argument. For completeness I captured the "indexed"
>>getter/setter that Castor provides and added an indexed getter/setter 
>>method but did not end up using it. I do not know if it will be useful.
>>If you like the changes you can roll them into the current Morph code 
>>base. At least the change to pick the specific no-argument getter and 
>>one argument setter needs to be there to avoid problems.
>>
>>I will create a bugzilla entry with attachments for all these files I 
>>modified and created.
>>
>>Thanks,
>>Alex Volanis, CISSP
>>Consultant Software Engineer
>>RSA Security Inc
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>    
>>
>
>  
>
>>Tool for open source databases. Create drag-&-drop reports. Save time 
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>morph-user mailing list
>>mor...@li...
>>https://lists.sourceforge.net/lists/listinfo/morph-user
>>
>> 
>>
>>    
>>
>
>
>
>
>--__--__--
>
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>
>End of morph-user Digest
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>  
>

[morph-user] Re: Contribution to Morph

[Volanis, A. <AVo...@rs...>]

Hi Matt,

Yes, I agree that errorOnMissingProperty is better and true by default
would make it much more useful. I have been setting it to true always
because the project I used this in involves many transformations that
are still evolving and it is easier if the transformers catch my
fat-fingering for me ;-)

I think PropertyNameMatchingCopier could really be derived by
SelectivePropertyNameMatchingCopier if you have the copyImpl invoke
setPropertiesToCopy and the execute super.copyImpl().

I believe the Castor library used exactly this definition of JavaBean
Collection access. I had coded an arrayMutator/arrayAccessor as well at
first but desided against it as it did not seem to add anything above
the normal mutator/accessor options.

If I find the time (which does not seem likely at this instant) I may
put together an example of how I coded the tree graph conversion. It
should be an interesting way to show the power of Morph.

Thanks again,
Alex

Date: Tue, 01 Feb 2005 00:30:29 -0500
From: Matt Sgarlata <sga...@us...>
To:  mor...@li...
Subject: Re: [morph-user] Contribution to Morph
Reply-To: mor...@li...

Hi Alex,

I'm glad you found Morph useful, and thank you for your contributions!

Quite right, it looks like PropertyNameMappingCopier slipped through the
cracks.  Thanks for the corrected implementation.  What would you think
of changing the strict property's name to errorOnMissingProperty?  That
is a little verbose, but I think also more descriptive.  I agree with
you, if you went to all the trouble of defining the mapping you probably
do want it to fail if a property name is missing.  I think we should we
go ahead and set strict or errorOnMissingProperty to true as the
default... what do you think?  I like how you used the Map's iterator to
impose ordering.  I'll definitely add that to the JavaDoc for the class.

I like your changes to the SelectivePropertyNameMatchingCopier.  I think
we should set the strict or errorOnMissingProperty option to true by
default for this class as well.  Also, looking back at my TODO that says
"PropertyNameMatchingCopier should extend this class, not vice-versa", I
think I changed my mind.  I like the hierarchy as it is.

You're right, if you define a mapping between property names, you
probably do want it to be bidirection.  Logically, what you're doing is
specifying an equivalence relation between two different types, so
normally the relation will be bidirectional.  I think we should remove
the option of making the PropertyNameMappingCopier unidirectional
entirely.  If someone wants to define a different mapping for the
different transformation directions, that person can just use two
different PropertyNameMappingCopiers.

Thanks for the fixes to NumberToTimeConverter and TimeToNumberConverter!

Actually, I recently found out the JavaBeans specification defines 4
methods for accessing elements of a JavaBean collection, as listed
below.  Thanks for taking care of the implementation :) Object[]
getArray() void setArray(Object[] array) Object getArray(int index) void
setArray(int index, Object value)

I'll make sure all this gets into the next release of Morph, although it
has of yet not been scheduled.  I'd like to get better test coverage
first, perhaps around 70%.  I also want to break out the composite
package into a separate project.

Matt

Volanis, Alexander wrote:

>Hi Matt,
>=20
>I have spent 3 weeks using your excellent Morph package to solve a=20
>deeply nested tree graph conversion. I successfully completed the=20
>"morphing" of a large XML schema processed by Castor objects into=20
>internal project specific Java Bean representations.
>=20
>As a result of this work I came up with a few interesting enhancements=20
>to Morph classes as well as a couple of bug fixes. I am submitting=20
>these classes for your review and possible inclusion into Morph 1.0. I=20
>found the Morph project to be the perfect match for the task at hand=20
>and congratulate you for the excellent work you produced.
>=20
>Without further rambling here is what I have to contribute:
>=20
>The PropertyNameMappingCopier seems to be a simple reincarnation of=20
>PropertyMatchingCopier. Probably a result of coding to fast to meet a=20
>deadline ;-) I attached the corrected implementation with some extra=20
>frills. I discovered it was too easy to fumble the property names and=20
>the copiers would happily skip over the mistyped properties leaving me=20
>wondering what was the problem. To solve this I added a "strict" flag=20
>to the copier that causes a TransformationException to be thrown when a

>specified property fails to copy. If I bothered to specify the property

>chances are I really want to know that it did get copied successfully.
>Furthermore, the order of copying the mapped properties is dictated by=20
>the Iterator of the Map. Thus if I use an OrderedHashMap I can control=20
>the order for the copy process.
>=20
>Another enhancement was that the order of copying selected properties=20
>in the SelectivePropertyNameMatchingCopier was not set. I reversed the=20
>process by iterating over the properties to copy instead of the=20
>sourceProperties. I also added the strict flag to this one as well.
>=20
>Finally, most of my conversions were bidirectional in the sense I am=20
>converting class X to class Y but I would also want to convert class Y=20
>to class X. This was done at first with a PropertyNameMappingCopier by=20
>specifying the mappings for each direction in the same Map. But it=20
>became obvious that it would be better to make the=20
>PropertyNameMappingCopier handle this. So, the=20
>PropertyNameTwoWayMappingCopier was born. This allows me to have my=20
>strict flag and can copy to/from easily.
>=20
>The TimeToNumberConverter and NumberToTimeConverter gave me trouble at=20
>first until I realized the default assignments for TimeConverter and=20
>NumberConverter were actually wrong. The defaults used=20
>Defaults.CONVERTER instead of Defaults.TIME_CONVERTER and=20
>Defaults.NUMBER_CONVERTER respectively. I changed the assignments of=20
>the defaults to the specific converters and the stack overflow=20
>exceptions I was getting were gone. I noticed version 0.8.1 fixed one=20
>of the two, the other one needs fixing as well.
>=20
>The last problem I encountered was that the Castor classes I was=20
>converting to/from have get/set methods with non-standard arguments.
>This was causing problems that I resolved by modifying the=20
>ObjectReflector class. When the bean ReflectionInfo is collected I pay=20
>attention to the arguments and use the getter with no arguments and=20
>setter with one argument. For completeness I captured the "indexed"
>getter/setter that Castor provides and added an indexed getter/setter=20
>method but did not end up using it. I do not know if it will be useful.
>If you like the changes you can roll them into the current Morph code=20
>base. At least the change to pick the specific no-argument getter and=20
>one argument setter needs to be there to avoid problems.
>
>I will create a bugzilla entry with attachments for all these files I=20
>modified and created.
>=20
>Thanks,
>Alex Volanis, CISSP
>Consultant Software Engineer
>RSA Security Inc
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting

>Tool for open source databases. Create drag-&-drop reports. Save time=20
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
> =20
>




--__--__--

_______________________________________________
morph-user mailing list
mor...@li...
https://lists.sourceforge.net/lists/listinfo/morph-user


End of morph-user Digest

[morph-user] Re: Collaboration between the OGNL and Morph projects

[Matt S. <sga...@us...>]

Hi Drew,

Thank you for your response!

I'm getting requests for more information about Morph from a lot of 
people, so I plan to flesh out a very basic user's guide with example 
use cases for Morph in the next couple weeks.  For now, I prepared a 
brief overview of Morph's features that you can look at in the attached 
PDF.  However, the use cases for Morph really aren't anything new.  They 
are basically the same use cases we have for using BeanUtils, OGNL and 
other similar libraries.

One difference in scope is that Morph takes the Converter mechanism to 
an extreme and aims to allow you to convert any arbitrary object graph 
into any different arbitrary object graph.  Alex Volanis wrote to me 
this week saying he had great success using Morph to solve an instance 
of this use case, so I think this goal has been achieved :)  Another 
difference between Morph and existing frameworks is that Morph aims to 
be much more configurable, extensible and flexible.  For example, 
BeanUtils can read bean information from Objects, Maps, and DynaBeans.  
No more, no less.  Morph supports those types out-of-the-box, but also 
allows you to define new types.  For example, Morph also out-of-the-box 
allows you to treat arrays and Collections as beans (the property names 
are numbers in this case).  Another example is that rather than define a 
single language that can be used to navigate an object graph, any 
language can be defined.  Out-of-the-box Morph has the SimpleLanguage, 
which will correctly interpret expressions written in the languages used 
by BeanUtils, JSTL EL, JEXL, Velocity or Spring.  However, you are free 
to define other (perhaps more powerful?) languages as well.

This brings me to my original purpose in writing to you: I like OGNL's 
advanced features like projection and selection, and I am wondering if 
Morph's Language interface is expressive enough to correctly interpret 
expressions written in OGNL, assuming someone were to write an 
OgnlLanguage for Morph.  Or, flipping things around, could OGNL be made 
more powerful by plugging into Morph's extensibility and type converter 
capabilities?  This would provide a very easy mechanism for someone to, 
for example, define a new type upon which a selection or projection 
operation could be performed.  Honestly I have no idea in which 
direction the integration should take place: should OGNL start to tap 
into Morph's power, or should Morph aim to duplicate OGNL's capabilities 
with a new Language implementation?

Hopefully this email gives you a good enough idea of the use cases for 
Morph that we can go ahead and talk about possibilities for Morph/OGNL 
integration.  If not, more thorough documentation is coming soon!

Matt

Drew Davidson wrote:

> Matt Sgarlata wrote:
>
>> I'm the author of a framework that provides some of the same features 
>> as OGNL, but has a different focus.  The framework I'm working on is 
>> called Morph and its focus was originally on providing a simple 
>> interface that allowed you to convert information from one format to 
>> another.  It quickly grew to providing all the features in Commons 
>> BeanUtils and more.  It doesn't support the advanced features of OGNL 
>> like projection and selection.  However, I think the Converter 
>> mechanism in Morph is simpler and cleaner than the TypeConverter 
>> mechanism I see in OGNL.
>>
> Hello, Matt!  I'm glad to hear from you about your project!
>
> A TypeConverter implementation could certainly use the Morph Converter.
>
>> Anyway, I'm wondering if we might be able to collaborate in some way 
>> to either bring the power of OGNL to Morph or bring the ease of 
>> Morph's converters to OGNL.  What do you think?  Attached is a 
>> reference document that provides a very brief overview of Morph, just 
>> so you can get a little familiar with Morph.
>
>
> I think that you need to provide several use cases to demonstrate what 
> you are doing with Morph.  The documentation and the website is very 
> abstract and vague and concrete examples would certainly give people 
> more of a feel for what Morph can do and how to do it.  Something like 
> a "quickstart" for web apps or other use cases would be great.
>
> I'm not sure right now how OGNL and Morph could be used together since 
> I'm a little fuzzy on how Morph is used.  What do you suggest?
>
> - Drew
>

Re: [morph-user] Contribution to Morph

[Matt S. <sga...@us...>]

Hi Alex,

I'm glad you found Morph useful, and thank you for your contributions!

Quite right, it looks like PropertyNameMappingCopier slipped through the 
cracks.  Thanks for the corrected implementation.  What would you think 
of changing the strict property's name to errorOnMissingProperty?  That 
is a little verbose, but I think also more descriptive.  I agree with 
you, if you went to all the trouble of defining the mapping you probably 
do want it to fail if a property name is missing.  I think we should we 
go ahead and set strict or errorOnMissingProperty to true as the 
default... what do you think?  I like how you used the Map's iterator to 
impose ordering.  I'll definitely add that to the JavaDoc for the class.

I like your changes to the SelectivePropertyNameMatchingCopier.  I think 
we should set the strict or errorOnMissingProperty option to true by 
default for this class as well.  Also, looking back at my TODO that says 
"PropertyNameMatchingCopier should extend this class, not vice-versa", I 
think I changed my mind.  I like the hierarchy as it is.

You're right, if you define a mapping between property names, you 
probably do want it to be bidirection.  Logically, what you're doing is 
specifying an equivalence relation between two different types, so 
normally the relation will be bidirectional.  I think we should remove 
the option of making the PropertyNameMappingCopier unidirectional 
entirely.  If someone wants to define a different mapping for the 
different transformation directions, that person can just use two 
different PropertyNameMappingCopiers.

Thanks for the fixes to NumberToTimeConverter and TimeToNumberConverter!

Actually, I recently found out the JavaBeans specification defines 4 
methods for accessing elements of a JavaBean collection, as listed 
below.  Thanks for taking care of the implementation :)
Object[] getArray()
void setArray(Object[] array)
Object getArray(int index)
void setArray(int index, Object value)

I'll make sure all this gets into the next release of Morph, although it 
has of yet not been scheduled.  I'd like to get better test coverage 
first, perhaps around 70%.  I also want to break out the composite 
package into a separate project.

Matt

Volanis, Alexander wrote:

>Hi Matt,
> 
>I have spent 3 weeks using your excellent Morph package to solve a
>deeply nested tree graph conversion. I successfully completed the
>"morphing" of a large XML schema processed by Castor objects into
>internal project specific Java Bean representations.
> 
>As a result of this work I came up with a few interesting enhancements
>to Morph classes as well as a couple of bug fixes. I am submitting these
>classes for your review and possible inclusion into Morph 1.0. I found
>the Morph project to be the perfect match for the task at hand and
>congratulate you for the excellent work you produced.
> 
>Without further rambling here is what I have to contribute:
> 
>The PropertyNameMappingCopier seems to be a simple reincarnation of
>PropertyMatchingCopier. Probably a result of coding to fast to meet a
>deadline ;-) I attached the corrected implementation with some extra
>frills. I discovered it was too easy to fumble the property names and
>the copiers would happily skip over the mistyped properties leaving me
>wondering what was the problem. To solve this I added a "strict" flag to
>the copier that causes a TransformationException to be thrown when a
>specified property fails to copy. If I bothered to specify the property
>chances are I really want to know that it did get copied successfully.
>Furthermore, the order of copying the mapped properties is dictated by
>the Iterator of the Map. Thus if I use an OrderedHashMap I can control
>the order for the copy process.
> 
>Another enhancement was that the order of copying selected properties in
>the SelectivePropertyNameMatchingCopier was not set. I reversed the
>process by iterating over the properties to copy instead of the
>sourceProperties. I also added the strict flag to this one as well.
> 
>Finally, most of my conversions were bidirectional in the sense I am
>converting class X to class Y but I would also want to convert class Y
>to class X. This was done at first with a PropertyNameMappingCopier by
>specifying the mappings for each direction in the same Map. But it
>became obvious that it would be better to make the
>PropertyNameMappingCopier handle this. So, the
>PropertyNameTwoWayMappingCopier was born. This allows me to have my
>strict flag and can copy to/from easily.
> 
>The TimeToNumberConverter and NumberToTimeConverter gave me trouble at
>first until I realized the default assignments for TimeConverter and
>NumberConverter were actually wrong. The defaults used
>Defaults.CONVERTER instead of Defaults.TIME_CONVERTER and
>Defaults.NUMBER_CONVERTER respectively. I changed the assignments of the
>defaults to the specific converters and the stack overflow exceptions I
>was getting were gone. I noticed version 0.8.1 fixed one of the two, the
>other one needs fixing as well.
> 
>The last problem I encountered was that the Castor classes I was
>converting to/from have get/set methods with non-standard arguments.
>This was causing problems that I resolved by modifying the
>ObjectReflector class. When the bean ReflectionInfo is collected I pay
>attention to the arguments and use the getter with no arguments and
>setter with one argument. For completeness I captured the "indexed"
>getter/setter that Castor provides and added an indexed getter/setter
>method but did not end up using it. I do not know if it will be useful.
>If you like the changes you can roll them into the current Morph code
>base. At least the change to pick the specific no-argument getter and
>one argument setter needs to be there to avoid problems.
>
>I will create a bugzilla entry with attachments for all these files I
>modified and created.
> 
>Thanks,
>Alex Volanis, CISSP
>Consultant Software Engineer
>RSA Security Inc
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>  
>

[morph-user] Contribution to Morph

[Volanis, A. <AVo...@rs...>]

Hi Matt,
=20
I have spent 3 weeks using your excellent Morph package to solve a
deeply nested tree graph conversion. I successfully completed the
"morphing" of a large XML schema processed by Castor objects into
internal project specific Java Bean representations.
=20
As a result of this work I came up with a few interesting enhancements
to Morph classes as well as a couple of bug fixes. I am submitting these
classes for your review and possible inclusion into Morph 1.0. I found
the Morph project to be the perfect match for the task at hand and
congratulate you for the excellent work you produced.
=20
Without further rambling here is what I have to contribute:
=20
The PropertyNameMappingCopier seems to be a simple reincarnation of
PropertyMatchingCopier. Probably a result of coding to fast to meet a
deadline ;-) I attached the corrected implementation with some extra
frills. I discovered it was too easy to fumble the property names and
the copiers would happily skip over the mistyped properties leaving me
wondering what was the problem. To solve this I added a "strict" flag to
the copier that causes a TransformationException to be thrown when a
specified property fails to copy. If I bothered to specify the property
chances are I really want to know that it did get copied successfully.
Furthermore, the order of copying the mapped properties is dictated by
the Iterator of the Map. Thus if I use an OrderedHashMap I can control
the order for the copy process.
=20
Another enhancement was that the order of copying selected properties in
the SelectivePropertyNameMatchingCopier was not set. I reversed the
process by iterating over the properties to copy instead of the
sourceProperties. I also added the strict flag to this one as well.
=20
Finally, most of my conversions were bidirectional in the sense I am
converting class X to class Y but I would also want to convert class Y
to class X. This was done at first with a PropertyNameMappingCopier by
specifying the mappings for each direction in the same Map. But it
became obvious that it would be better to make the
PropertyNameMappingCopier handle this. So, the
PropertyNameTwoWayMappingCopier was born. This allows me to have my
strict flag and can copy to/from easily.
=20
The TimeToNumberConverter and NumberToTimeConverter gave me trouble at
first until I realized the default assignments for TimeConverter and
NumberConverter were actually wrong. The defaults used
Defaults.CONVERTER instead of Defaults.TIME_CONVERTER and
Defaults.NUMBER_CONVERTER respectively. I changed the assignments of the
defaults to the specific converters and the stack overflow exceptions I
was getting were gone. I noticed version 0.8.1 fixed one of the two, the
other one needs fixing as well.
=20
The last problem I encountered was that the Castor classes I was
converting to/from have get/set methods with non-standard arguments.
This was causing problems that I resolved by modifying the
ObjectReflector class. When the bean ReflectionInfo is collected I pay
attention to the arguments and use the getter with no arguments and
setter with one argument. For completeness I captured the "indexed"
getter/setter that Castor provides and added an indexed getter/setter
method but did not end up using it. I do not know if it will be useful.
If you like the changes you can roll them into the current Morph code
base. At least the change to pick the specific no-argument getter and
one argument setter needs to be there to avoid problems.

I will create a bugzilla entry with attachments for all these files I
modified and created.
=20
Thanks,
Alex Volanis, CISSP
Consultant Software Engineer
RSA Security Inc

[morph-user] Re: Morph Beta 1 Released

[Dakota J. <dak...@gm...>]

Thanks, Matt.  I have been looking forward to this.  I am going to
spend the afternoon just nosing around in Morph.

Jack


"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

[morph-user] Morph Beta 1 Released

[Matt S. <sga...@us...>]

Morph is a Java framework that eases the internal interoperability of an 
application. As information flows through an application, it undergoes 
multiple transformations. Morph provides a standard way to implement 
these transformations.

The goal of this release is to provide a near-final look at the Morph 
1.0 API.  However, if someone has a good idea for an API improvement 
before the Morph 1.0 release, it will certainly be incorporated.  Also, 
before the 1.0 release, the composite package will probably be moved 
into its own SourceForge project.  New in this release:
- Test coverage at 61.1%
- New wrapper package

You can access the release at http://morph.sourceforge.net

Matt

[morph-user] Morph 0.7.2 Released

[Matt S. <sga...@us...>]

Morph 0.7.2 is an alpha release.  I was hoping for it to be a beta, but 
it had been so long since 0.6 I figured I would just go ahead and give 
you what I have so far.  New in this release:

    * Defined many more transformers and refactored the existing ones
    * Introduced a new composite package that provides a standard way
      for implementing the Composite design pattern (let me know
      <mailto:sga...@us...> if you think I should
      split this off into a separate project)
    * Refactored the composite reflectors and transformers to use the
      new composite package
    * Apache Jakarta Velocity <http://jakarta.apache.org/velocity>
      integration
    * Experimental Apache Jakarta Commons Chain
      <http://jakarta.apache.org/commons/chain> integration

Matt

[morph-user] [announce] Morph 0.6.4 Released

[Matt S. <sga...@us...>]

Morph 0.6.4 is an alpha release.  New in this release:
* Improved test coverage
* Bug fixes

Matt

[morph-user] [announce] Morph 0.6.3 Released

[Matt S. <sga...@us...>]

Morph 0.6.3 is an alpha release.  New in this release:
* Improved test coverage
* Bug fixes

Matt

[morph-user] [announce] Morph 0.6.2 Released

[Matt S. <sga...@us...>]

Morph 0.6.2 is an alpha release.  New in this release:

    * Combined the many different DelegatingReflectors into a single
      DelegatingReflector that implements every Reflector interface
    * Detect if Servlet API is present, and if so include the web
      reflectors in the DelegatingReflector
    * Detect if BeanUtils is present, and if so include the
      DynaBeanReflector in DelegatingReflector
    * Refactored container copiers (combined the old
      BaseContainerReflector, GrowableContainerReflector and
      MutableIndexedContainerReflector into just one class,
      ContainerReflectorCopier)
    * Make all bean reflectors expose the 'class' read-only
      pseudo-property so random bean-like objects
    * Made sizable reflectors expose a size pseudo-property, like JEXL.
    * Introduced the |MorphFilter
      <http://morph.sourceforge.net/apidocs/net/sf/morph/web/MorphFilter.html>|
      which places a |HttpServletContext
      <http://morph.sourceforge.net/apidocs/net/sf/morph/context/contexts/HttpServletContext.html>|
      in each request. This exposes Morph's power to JSPs


Matt

[morph-user] Re: [beanutils] Beans and Maps mixed up in PropertyUtils

[Matt S. <sga...@us...>]

Hi Jack,

I'm glad you like Morph :)  It's already starting to make my life much 
easier in the apps I'm working on.

I looked at your post in BugZilla again, and it looks like 
BeanUtils.populate is what you're trying to overwrite.  The equivalent 
in Morph is Morph.copy.  I'm not clear on the specifics of your use case 
but Morph.copy might just work out-of-the-box with no extra 
configuration needed.  I think for your use case, you would need to 
override RequestProcessor.processPopulate so that it uses Morph to read 
values from the request instead of BeanUtils.  It should just be a 
matter of calling Morph.copy(actionForm, request).

Does this answer your question?  It might help me if you send me your 
ActionForm... then I could write a test case to verify that Morph will 
do what you need.

Matt

Dakota Jack wrote:

>Hi, Matt,
>
>I am taking a look now.  Looks like A-1 work to me.  Nice!  Could you
>spare me some minutes and steer me to the code that does what
>PropertyUtils does in the existing Jakarta commons beanutils?  Thanks!
> That is where the difference will be.  If this does not make sense to
>you (however, I am sure it did), then I need your code where it
>determines how to return values from the bean equivalent to beanutils
>in the existing beanutils.
>
>Jack
>
>
>On Fri, 17 Dec 2004 14:44:16 -0500, Matt Sgarlata
><mat...@ve...> wrote:
>  
>
>>Hi Jack... did you have a chance to take a look?  What did you think?
>>
>>The API is getting fairly solid at this point and I expect a 1.0 final
>>release in the next couple months.  If there are any requirements that
>>the framework doesn't meet, let me know and I'll focus my efforts on
>>those areas first so you can have a beta framework to play with until
>>the final release arrives.
>>
>>Matt
>>
>>Dakota Jack wrote:
>>
>>    
>>
>>>Cool, Matt,
>>>
>>>Let me look around and I will definitely get back to you.
>>>
>>>Jack
>>>
>>>
>>>On Sun, 12 Dec 2004 15:09:56 -0500, Matt Sgarlata
>>><sga...@us...> wrote:
>>>
>>>
>>>      
>>>
>>>>Hi Jack, I saw Craig's (hostile?) response to the bug you entered in
>>>>BugZilla for BeanUtils.  I too am frustrated with some of the design choices
>>>>that were made in BeanUtils, so I started my own framework that is much more
>>>>configurable and extensible than BeanUtils.  Think of it as BeanUtils 2.0 ;)
>>>>It has already received some positive initial comments from some of the
>>>>committers on BeanUtils, specifically from Robert Durrel Donkin.  For more
>>>>information, see http://morph.sourceforge.net
>>>>
>>>>I'm not sure I completely understand the exact issue you are facing, but if
>>>>you are willing to give the Morph framework some serious consideration, I
>>>>would be more than happy to incorporate the changes you need directly into
>>>>the Morph framework.
>>>>
>>>>Matt
>>>>
>>>>For the record, here's the thread from Bugzilla:
>>>>
>>>>If we want to use BeanUtils to populate a bean, which we do in Struts with
>>>>an ActionForm, for example, and want to use the same bean to deliver data to
>>>>a view in an MVC framework, which we also do in Struts, again with an
>>>>ActionForm, we cannot do so by making the bean implement a Map. The reason
>>>>is that PropertyUtils automagically treats Maps in a way that won't allow us
>>>>to populate a bean that implements a map. This is a serious design flaw, I
>>>>think, in beanutils. One should be able to use the utilites to both populate
>>>>a bean and to use the same object to deliver data to a view as a map. The
>>>>offending code "works", I think, as follows: when you want to populate a
>>>>bean with BeanUtils (BeanUtilsBean) it hands the bean off to PropertyUtils
>>>>(PropertyUtilsBean). However, if PropertyUtils "discovers" that the bean is
>>>>a map, then population fails. I am not 100% certain that this is correct,
>>>>but it sure looks that way. I think that the inability to populate beans
>>>>that implements maps is unnecessary and a design flaw severely limiting the
>>>>use of beanutils. Here is what happens with Struts, for example, if an
>>>>ActionForm bean implements a Map and the Struts controller attempts to
>>>>populate the ActionForm bean: java.lang.IllegalArgumentException: Null
>>>>property value for 'submit' at
>>>>org.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:755)
>>>>at
>>>>org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:801)
>>>>at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:881) at
>>>>org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) at
>>>>org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) at
>>>>org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
>>>>at
>>>>org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
>>>>at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>>>>at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) at
>>>>javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at
>>>>javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
>>>>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
>>>>at
>>>>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
>>>>at com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:19) at
>>>>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:233)
>>>>at
>>>>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
>>>>at
>>>>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257)
>>>>at
>>>>org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
>>>>at
>>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
>>>>at
>>>>org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
>>>>at
>>>>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
>>>>at
>>>>org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
>>>>at
>>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
>>>>at
>>>>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
>>>>at
>>>>org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
>>>>at
>>>>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
>>>>at
>>>>org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
>>>>at
>>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
>>>>at
>>>>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
>>>>at
>>>>org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
>>>>at
>>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
>>>>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at
>>>>org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206) at
>>>>org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:833)
>>>>at
>>>>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:732)
>>>>at
>>>>org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:619)
>>>>at
>>>>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688)
>>>>at java.lang.Thread.run(Thread.java:534)
>>>>
>>>>------- Additional Comment #1 From Dakota Jack 2004-12-12 08:18 [reply]
>>>>------- The central point is that a single bean ought to be able to retrieve
>>>>and to supply data from the request/response http exchanges. The present
>>>>beanutils architecture makes that to a large extent difficult by making
>>>>certain sorts of objects incapable of being retrieval objects, e.g. Map
>>>>objects. A utilities program ought not to enforce this sort of architectural
>>>>restriction on the applications it services. I would provisionally suggest
>>>>that the use of property utils by bean utils be split in its behavior
>>>>depending upon whether or not the action is one of population (retrieval)
>>>>versus one of creating the response (supplying data). Jack
>>>>
>>>>------- Additional Comment #2 From Craig McClanahan 2004-12-12 20:56
>>>>[reply] ------- It is far too late to make a fundamental change in the
>>>>architecture of a module that has its current behavior relied on by many
>>>>thousands of existing applications. At best, you should think of this as an
>>>>RFE for some additional classes that have different behavior. The current
>>>>architecture was deliberately designed to solve the problems it does solve,
>>>>and it continues to do so. However, you are also starting from an incorrect
>>>>assumption that what you want to achieve is not possible with the current
>>>>architecture. Simply program the get and put methods of your Map
>>>>implementation to call through to the corresponding getters and setters for
>>>>keys that are the properties of this class, and do the normal thing for keys
>>>>that are not properties. You can do this for specific classes fairly easily,
>>>>or you can use the solution provided by
>>>>org.apache.commons.chain.impl.ContextBase that does this thing generally
>>>>(using reflection to identify what's a property and what's not).
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>

[morph-user] Re: [beanutils] Beans and Maps mixed up in PropertyUtils

[Dakota J. <dak...@gm...>]

Cool, Matt,

Let me look around and I will definitely get back to you.

Jack


On Sun, 12 Dec 2004 15:09:56 -0500, Matt Sgarlata
<sga...@us...> wrote:
>  Hi Jack, I saw Craig's (hostile?) response to the bug you entered in
> BugZilla for BeanUtils.  I too am frustrated with some of the design choices
> that were made in BeanUtils, so I started my own framework that is much more
> configurable and extensible than BeanUtils.  Think of it as BeanUtils 2.0 ;)
>  It has already received some positive initial comments from some of the
> committers on BeanUtils, specifically from Robert Durrel Donkin.  For more
> information, see http://morph.sourceforge.net
>  
>  I'm not sure I completely understand the exact issue you are facing, but if
> you are willing to give the Morph framework some serious consideration, I
> would be more than happy to incorporate the changes you need directly into
> the Morph framework.
>  
>  Matt
>  
>  For the record, here's the thread from Bugzilla:
>  
>  If we want to use BeanUtils to populate a bean, which we do in Struts with
> an ActionForm, for example, and want to use the same bean to deliver data to
> a view in an MVC framework, which we also do in Struts, again with an
> ActionForm, we cannot do so by making the bean implement a Map. The reason
> is that PropertyUtils automagically treats Maps in a way that won't allow us
> to populate a bean that implements a map. This is a serious design flaw, I
> think, in beanutils. One should be able to use the utilites to both populate
> a bean and to use the same object to deliver data to a view as a map. The
> offending code "works", I think, as follows: when you want to populate a
> bean with BeanUtils (BeanUtilsBean) it hands the bean off to PropertyUtils
> (PropertyUtilsBean). However, if PropertyUtils "discovers" that the bean is
> a map, then population fails. I am not 100% certain that this is correct,
> but it sure looks that way. I think that the inability to populate beans
> that implements maps is unnecessary and a design flaw severely limiting the
> use of beanutils. Here is what happens with Struts, for example, if an
> ActionForm bean implements a Map and the Struts controller attempts to
> populate the ActionForm bean: java.lang.IllegalArgumentException: Null
> property value for 'submit' at
> org.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:755)
> at
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:801)
> at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:881) at
> org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) at
> org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) at
> org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
> at
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
> at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
> at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> at com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:19) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:233)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
> at
> org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at
> org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206) at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:833)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:732)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:619)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688)
> at java.lang.Thread.run(Thread.java:534) 
>  
>  ------- Additional Comment #1 From Dakota Jack 2004-12-12 08:18 [reply]
> ------- The central point is that a single bean ought to be able to retrieve
> and to supply data from the request/response http exchanges. The present
> beanutils architecture makes that to a large extent difficult by making
> certain sorts of objects incapable of being retrieval objects, e.g. Map
> objects. A utilities program ought not to enforce this sort of architectural
> restriction on the applications it services. I would provisionally suggest
> that the use of property utils by bean utils be split in its behavior
> depending upon whether or not the action is one of population (retrieval)
> versus one of creating the response (supplying data). Jack 
>  
>  ------- Additional Comment #2 From Craig McClanahan 2004-12-12 20:56
> [reply] ------- It is far too late to make a fundamental change in the
> architecture of a module that has its current behavior relied on by many
> thousands of existing applications. At best, you should think of this as an
> RFE for some additional classes that have different behavior. The current
> architecture was deliberately designed to solve the problems it does solve,
> and it continues to do so. However, you are also starting from an incorrect
> assumption that what you want to achieve is not possible with the current
> architecture. Simply program the get and put methods of your Map
> implementation to call through to the corresponding getters and setters for
> keys that are the properties of this class, and do the normal thing for keys
> that are not properties. You can do this for specific classes fairly easily,
> or you can use the solution provided by
> org.apache.commons.chain.impl.ContextBase that does this thing generally
> (using reflection to identify what's a property and what's not). 
>  


-- 


"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~