morph-developer — For developers of the Morph framework. NOT for questions.

[morph-developer] [ morph-Bugs-1344515 ] Incorrect handling of empty collections

[SourceForge.net <no...@so...>]

Bugs item #1344515, was opened at 2005-10-31 23:00
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1344515&group_id=124910

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 9
Submitted By: Eduard Letifov (techtime)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect handling of empty collections

Initial Comment:
I am using Morph 0.9.1

When I am transform complex object graphs I encounter 
a following incorrect behavior: if a source object contains 
multiple empty collections such as TreeSet in different 
fields, DelegatingTransformer assumes in .hasVisited() 
(line 180) that they are equal, and the resulting 
(transformed) values can be cached and re-used. 

This is incorrect in previous transformation of an empty 
collection resulted in an object of a different type (as 
dictated by corresponding destination type)

This causes the invocation chain BaseReflector.set -> 
ObjectReflector.setImpl -> ReflectionInfo.set -> 
MethodHolder.invokeMethod to fail, as argument type to 
mutator is incorrect.

Example Test Case:

public class ConversionTest extends TestCase {

    public static class A {
    }

    public static class B {
    }


    public static class Destination {
        A[] field1;
        B[] field2;

        public A[] getField1() {
            return field1;
        }

        public void setField1(A[] field1) {
            this.field1 = field1;
        }

        public B[] getField2() {
            return field2;
        }

        public void setField2(B[] field2) {
            this.field2 = field2;
        }
    }

    public static class Source {
        Set field1 = new TreeSet();
        Set field2 = new TreeSet();

        public Set getField1() {
            return field1;
        }

        public void setField1(Set field1) {
            this.field1 = field1;
        }

        public Set getField2() {
            return field2;
        }

        public void setField2(Set field2) {
            this.field2 = field2;
        }
    }

    public void testBug() throws Exception {

        Morph.convert(Destination.class, new Source());

    }
}

Results in:
net.sf.morph.transform.TransformationException: Error 
copying source 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Source@765a16 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Source) to destination 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination@16fe0f4 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
py(BaseTransformer.java:348)
	at 
net.sf.morph.transform.transformers.DelegatingTransform
er.convertImpl(DelegatingTransformer.java:178)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
nvert(BaseTransformer.java:245)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
nvert(BaseTransformer.java:257)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.composite.util.DelegatingInvocationHandler.invoke
(DelegatingInvocationHandler.java:53)
	at $Proxy7.convert(Unknown Source)
	at net.sf.morph.Morph.convert(Morph.java:82)
	at 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest.testBug(ConversionTest.java:180)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
com.intellij.rt.execution.junit2.JUnitStarter.main
(JUnitStarter.java:31)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
com.intellij.rt.execution.application.AppMain.main
(AppMain.java:86)
Caused by: net.sf.morph.reflect.ReflectionException: 
Unable to set property 'field2' of bean 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination@16fe0f4 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination) to 
[Lcom.metservice.ice.breaker.snowie.cytrack.impl.Conve
rsionTest$A;@a9c09e
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:550)
	at 
net.sf.morph.reflect.reflectors.DelegatingReflector.setImpl
(DelegatingReflector.java:161)
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:544)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.composite.util.DelegatingInvocationHandler.invoke
(DelegatingInvocationHandler.java:53)
	at $Proxy0.set(Unknown Source)
	at 
net.sf.morph.transform.copiers.BasePropertyNameCopier
.copyProperty(BasePropertyNameCopier.java:120)
	at 
net.sf.morph.transform.copiers.PropertyNameMatchingC
opier.copyImpl(PropertyNameMatchingCopier.java:86)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
py(BaseTransformer.java:342)
	... 34 more
Caused by: java.lang.IllegalArgumentException: 
argument type mismatch
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.morph.reflect.support.MethodHolder.invokeMutator
(MethodHolder.java:89)
	at 
net.sf.morph.reflect.support.ReflectionInfo.set
(ReflectionInfo.java:132)
	at 
net.sf.morph.reflect.reflectors.ObjectReflector.setImpl
(ObjectReflector.java:260)
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:544)
	... 45 more



----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-11-07 10:34

Message:
Logged In: YES 
user_id=1161666

I have verified this is a bug.  Thanks for the test case! 
I'll work on getting this fixed ASAP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1344515&group_id=124910

[morph-developer] [ morph-Bugs-1344515 ] Incorrect handling of empty collections

[SourceForge.net <no...@so...>]

Bugs item #1344515, was opened at 2005-11-01 07:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1344515&group_id=124910

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eduard Letifov (techtime)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect handling of empty collections

Initial Comment:
I am using Morph 0.9.1

When I am transform complex object graphs I encounter 
a following incorrect behavior: if a source object contains 
multiple empty collections such as TreeSet in different 
fields, DelegatingTransformer assumes in .hasVisited() 
(line 180) that they are equal, and the resulting 
(transformed) values can be cached and re-used. 

This is incorrect in previous transformation of an empty 
collection resulted in an object of a different type (as 
dictated by corresponding destination type)

This causes the invocation chain BaseReflector.set -> 
ObjectReflector.setImpl -> ReflectionInfo.set -> 
MethodHolder.invokeMethod to fail, as argument type to 
mutator is incorrect.

Example Test Case:

public class ConversionTest extends TestCase {

    public static class A {
    }

    public static class B {
    }


    public static class Destination {
        A[] field1;
        B[] field2;

        public A[] getField1() {
            return field1;
        }

        public void setField1(A[] field1) {
            this.field1 = field1;
        }

        public B[] getField2() {
            return field2;
        }

        public void setField2(B[] field2) {
            this.field2 = field2;
        }
    }

    public static class Source {
        Set field1 = new TreeSet();
        Set field2 = new TreeSet();

        public Set getField1() {
            return field1;
        }

        public void setField1(Set field1) {
            this.field1 = field1;
        }

        public Set getField2() {
            return field2;
        }

        public void setField2(Set field2) {
            this.field2 = field2;
        }
    }

    public void testBug() throws Exception {

        Morph.convert(Destination.class, new Source());

    }
}

Results in:
net.sf.morph.transform.TransformationException: Error 
copying source 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Source@765a16 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Source) to destination 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination@16fe0f4 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
py(BaseTransformer.java:348)
	at 
net.sf.morph.transform.transformers.DelegatingTransform
er.convertImpl(DelegatingTransformer.java:178)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
nvert(BaseTransformer.java:245)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
nvert(BaseTransformer.java:257)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.composite.util.DelegatingInvocationHandler.invoke
(DelegatingInvocationHandler.java:53)
	at $Proxy7.convert(Unknown Source)
	at net.sf.morph.Morph.convert(Morph.java:82)
	at 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest.testBug(ConversionTest.java:180)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
com.intellij.rt.execution.junit2.JUnitStarter.main
(JUnitStarter.java:31)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
com.intellij.rt.execution.application.AppMain.main
(AppMain.java:86)
Caused by: net.sf.morph.reflect.ReflectionException: 
Unable to set property 'field2' of bean 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination@16fe0f4 (class 
com.metservice.ice.breaker.snowie.cytrack.impl.Convers
ionTest$Destination) to 
[Lcom.metservice.ice.breaker.snowie.cytrack.impl.Conve
rsionTest$A;@a9c09e
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:550)
	at 
net.sf.morph.reflect.reflectors.DelegatingReflector.setImpl
(DelegatingReflector.java:161)
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:544)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.composite.util.DelegatingInvocationHandler.invoke
(DelegatingInvocationHandler.java:53)
	at $Proxy0.set(Unknown Source)
	at 
net.sf.morph.transform.copiers.BasePropertyNameCopier
.copyProperty(BasePropertyNameCopier.java:120)
	at 
net.sf.morph.transform.copiers.PropertyNameMatchingC
opier.copyImpl(PropertyNameMatchingCopier.java:86)
	at 
net.sf.morph.transform.transformers.BaseTransformer.co
py(BaseTransformer.java:342)
	... 34 more
Caused by: java.lang.IllegalArgumentException: 
argument type mismatch
	at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at 
net.sf.morph.reflect.support.MethodHolder.invokeMutator
(MethodHolder.java:89)
	at 
net.sf.morph.reflect.support.ReflectionInfo.set
(ReflectionInfo.java:132)
	at 
net.sf.morph.reflect.reflectors.ObjectReflector.setImpl
(ObjectReflector.java:260)
	at 
net.sf.morph.reflect.reflectors.BaseReflector.set
(BaseReflector.java:544)
	... 45 more



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1344515&group_id=124910

[morph-developer] [ morph-Bugs-1121605 ] ObjectReflector caching may have classloader issues?

[SourceForge.net <no...@so...>]

Bugs item #1121605, was opened at 2005-02-12 20:12
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121605&group_id=124910

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: ObjectReflector caching may have classloader issues?

Initial Comment:
Ensure ObjectReflector's caching works with multiple
classloaders

----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-06-15 12:27

Message:
Logged In: YES 
user_id=1161666

Until someone reports that this is a problem, I'm closing
this bug.

----------------------------------------------------------------------

Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-02-12 20:13

Message:
Logged In: YES 
user_id=1161666

If there are issues, consider adding an option to turn
caching off for ObjectReflector.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121605&group_id=124910

[morph-developer] [ morph-Bugs-1121596 ] Have web reflectors expose additional implicit properties?

[SourceForge.net <no...@so...>]

Bugs item #1121596, was opened at 2005-02-12 20:04
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121596&group_id=124910

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Have web reflectors expose additional implicit properties?

Initial Comment:
Consider fixing the web reflectors so that they expose
implicit properties like requestScope, sessionScope,
etc (following the JSTL).  Along this same line of
thinking, should we expose all the JavaBeans properties
of an HTTP request?  If so, how do we deal with
collisions between the JavaBeans properties and HTTP
request attributes?  Should this be a JavaBean property
of the converter?

----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-06-15 12:27

Message:
Logged In: YES 
user_id=1161666

No, if this type of thing is added it will be added to the
Context implementations instead of to the reflectors.  There
are already enough issues with there being two reflectors
for request parameters ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121596&group_id=124910

[morph-developer] [ morph-Bugs-1121502 ] Allow the contents of untyped containers to be converted

[SourceForge.net <no...@so...>]

Bugs item #1121502, was opened at 2005-02-12 16:04
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121502&group_id=124910

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow the contents of untyped containers to be converted

Initial Comment:
Right now if you want to do a transformation of
something like PersonDAO[] -> PersonVO[], you have no
problem.  If you want to do a transformation of
List<PersonDAO> -> List<PersonVO> you are out of luck.
 There needs to be a way to do this both with JDK 1.5
parameterized types and with older JDKs that don't have
parameterized types.

----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-06-15 12:25

Message:
Logged In: YES 
user_id=1161666

Fixed for JDK 1.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1121502&group_id=124910

[morph-developer] [ morph-Bugs-1120983 ] Detect transformations of cyclic graphs

[SourceForge.net <no...@so...>]

Bugs item #1120983, was opened at 2005-02-11 14:06
Message generated for change (Settings changed) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1120983&group_id=124910

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Detect transformations of cyclic graphs

Initial Comment:
Detect when there is a cycle in a graph of objects so
as to avoid starting an infinite loop

----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-04-19 18:28

Message:
Logged In: YES 
user_id=1161666

Fixed in Morph 0.8.x.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1120983&group_id=124910

[morph-developer] [ morph-Bugs-1113428 ] Contribution to Morph and some fixes for Castor Objects

[SourceForge.net <no...@so...>]

Bugs item #1113428, was opened at 2005-01-31 15:32
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1113428&group_id=124910

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 9
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Contribution to Morph and some fixes for Castor Objects

Initial Comment:
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.
 
Thanks,
Alex Volanis, CISSP
Consultant Software Engineer
RSA Security Inc


----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-04-19 18:27

Message:
Logged In: YES 
user_id=1161666

These bug fixes and design ideas are implemented in Morph 0.9.1

----------------------------------------------------------------------

Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-02-12 20:20

Message:
Logged In: YES 
user_id=1161666

These changes are great!  Morph 0.8.2 incorporates most of
them, but there's still more to do to get your fixes 100%
encorporated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1113428&group_id=124910

[morph-developer] [ morph-Bugs-1185528 ] Ensure converters can convert Morph's wrapper types

[SourceForge.net <no...@so...>]

Bugs item #1185528, was opened at 2005-04-18 20:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1185528&group_id=124910

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ensure converters can convert Morph's wrapper types

Initial Comment:
Need to make sure that converters can handle
transformations both to and from one of Morph's own
wrapper types.  This type of request wasn't originally
considered because the way these types were originally
envisioned to be requested was using the
Reflector.getWrapper method.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1185528&group_id=124910

[morph-developer] Morph Beta 2 Released

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

Morph beta 2 (aka 0.9.1) is available for download.  New in this release:

      More performance improvements, especially to the reflectors for
      HTTP requests, HTTP sessions, and servlet contexts. The test suite
      now executes in around 1.75s. 

      Moved the Composite package to its own project (check it out! 
      composite.sourceforge.net)

      More improvements to the ContainerCopier and PropertyCopiers 


Enjoy!

Matt

[morph-developer] [ morph-Bugs-1150077 ] Delete DelegatingConverter and DelegatingCopier

[SourceForge.net <no...@so...>]

Bugs item #1150077, was opened at 2005-02-23 15:08
Message generated for change (Comment added) made by sgarlatm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1150077&group_id=124910

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Matt Sgarlata (sgarlatm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Delete DelegatingConverter and DelegatingCopier

Initial Comment:
We just need the DelegatingTransformer.  This is
analagous to the DelegatingReflector: we don't have a
DelegatingBeanReflector,
DelegatingInstantiatingReflector, etc.  We just need one :)

----------------------------------------------------------------------

>Comment By: Matt Sgarlata (sgarlatm)
Date: 2005-04-06 17:22

Message:
Logged In: YES 
user_id=1161666

Fixed in Morph 0.8.4 (not yet released)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=700930&aid=1150077&group_id=124910

[morph-developer] Morph 0.8.3 Released

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

Hi everyone,

Morph 0.8.3 is now available.  The principle focus of this release was 
to provide you with support for transformations of cyclic graphs and 
transformations of untyped collections of objects of one type to untyped 
collections of objects of another type (e.g. List of PersonDAOs to List 
of PersonVOs).  In detail, the changes in this release are:

    * Performance improvements. It's difficult to quantify exactly how
      much better performance is, but the test suite now takes around 3
      seconds to execute on my laptop, whereas it used to take around 8
      seconds.
    * Improved support for nested transformations using the PropertyName
      copiers, ContainerCopier.
    * Morph now supports transformations of cyclic graphs.
    * net/sf/morph/morphContext.xml is a Spring application context file
      available as a classpath resource. This file defines common beans
      that you may need to reference in an application built on Spring.
    * Improved log output.

Matt

[morph-developer] 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

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-developer] FW: Some ideas for the current Morph release

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

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 =
work well and collapsing the SelectivePropertyNameMatchingCopier into =
the PropertyNameMatchingCopier does seem like the right thing to do.

Looking at the changes that you are in the process of making in =
PropertyNameMappingCopier I have one observation to make. I have used an =
OrderedMap as input to the setMapping() method to control the order of =
property copying. In some specialized cases the order in which =
properties are copied from one object to another is significant. Here is =
for example my reason for specifying the order. One of the objects I had =
to copy contained collections of beans that had ID properties. Within =
the rest of the object there were other objects that made references to =
the aforementioned beans. The references were plain object references =
that were established during the construction of the source object by =
reading an XML file that contained IDREFs. As I transformed the source =
objects I had to maintain the same references where applicable. My =
solution was to make an abstract converter class that all my copiers =
were derived from and look for the ID property present on any =
destination object. If there was one I collected the ID and the object =
reference in a Map. As the transformation progressed I would encounter =
the objects that needed to resolve the references to the new transformed =
objects. At that time I would get the required object references from my =
previously polulated Map and set them in my new referencing 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 =
functionality for me. You should probably consider using this in your =
BiDirectionalMap implementation as well. It may make sense to replace =
all Maps with something like that were there is a chance that a mapping =
order has to be preseved. At least there should be some way to specify =
that iteration order is significant and has to be maintained. In some =
cases it seems easy to just create a new plain HashMap from the one =
specified as input but 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. Castor 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 possible to use a fa=E7ade that =
can expose the best available HashMap implementation instead.

Another comment has to do with the "implicit properties". Using URI =
notation you could replace the string for the IMPLICIT_PROPERTY_CLASS =
with "urn:morph:properties:class" instead of just "class". This will =
guarantee that there will be no collisions with existing bean =
properties.

Finally one more observation. I think the ReflectionInfo class should =
also look for methods of the form addPropertyName(ObjectType arg) and =
addPropertyName(int index, ObjectType arg). These are common in cases of =
collection properties that are managed as arrays. Castor objects are =
full of these and to work with them I had to enable the Castor extra =
collection methods that give access to the underlying collection by =
reference. The reason I had to do this was that arrays (which is what I =
get otherwise) do not have a GrowableContainerReflector and cannot have =
elements added if they are not already sized to the necessary =
dimensions. If the ReflectionInfo can detect the presense of =
addPropertyName methods we can handle arrays as if they have a =
GrowableContainerReflector. In addition to getting the arrays to grow as =
needed it provides type checking that I lost when I had to use the =
Castor collection references.

I may do some work on this last topic myself if I have some free time =
(which has been severely limited lately). Let me know if there is =
anything that I can pick up from your TODO list.

Alex

[morph-developer] 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

[morph-developer] 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-developer] 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-developer] 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-developer] [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-developer] [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-developer] [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