morph-user Mailing List for Morph (Page 3)
Brought to you by:
orangeherbert,
sgarlatm
Menu
▾
▴
morph-user — For users of the Morph framework. Please post questions here.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(4) |
Feb
(12) |
Mar
(11) |
Apr
(6) |
May
|
Jun
(6) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(9) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Matt S. <Mat...@wh...> - 2007-01-26 22:15:46
|
Hi Bruce, unfortunately the ZIP you sent me did not contain the full
stack trace. The file is there, but its size is 0.
Matt
Bruce Lombardi wrote:
>
> Hi Matt,
>
>
>
> A while back I wrote to you and asked about making a copy where all
> the fields that were to be copied were not put in a map, but rather
> only the fields to be translated were supplied and the rest were
> copied without translation. I'm now starting to implement the approach
> you suggested for doing that in number 1 below, but I'm getting an
> error. The main error is shown below:
>
>
>
> net.sf.morph.transform.TransformationException: Failed to copy
> property 'maker' of "Audi" (class java.lang.String) to property
> 'manufacturer' of
>
> at
> net.sf.morph.transform.copiers.PropertyNameMappingCopier.copyImpl(PropertyNameMappingCopier.java:143)
>
>
>
> I'm trying to copy a DAO to a VO and translate Maker to Manufacture.
> Both properties exist and have manufacturers. I have attached a zip
> file with a complete error trace, both beans, the copyUtil class that
> is trying to do the copy and the CopyTest that is running the test.
> I'm using the morph-1.0.2.jar, which is something you put together for
> me to solve a different problem (the one copying maps I think).
>
>
>
> Any help you can give would be appreciated.
>
>
>
> -- Bruce
>
>
>
>
>
> -----Original Message-----
> *From:* Matt Sgarlata [mailto:Mat...@wh...]
> *Sent:* Friday, October 13, 2006 10:35 AM
> *To:* blo...@no...
> *Subject:* Re: Some questions and a Map copy problem
>
>
>
> Hi Bruce, here are some answers for you:
>
> 1) When using the PropertyNameMappingCopier you have to specify all
> field names that you would like copied. You could always
> programmatically retrieve the list of property names that are the same
> between both objects (for example, using Morph.getPropertyNames),
> construct the map, and then change the Map to account for the
> 2) You can use the PropertyNameMappingCopier for this purpose, because
> it only copies the fields that you explicitly mention in the Map. You
> can also use the PropertyNameMatchingCopier and set its fieldsToCopy
> property to only those fields you would like copied.
> 3) It's hard to tell what's going on in your stack trace, because the
> cause of the transformation error has been "lost" in your output. If
> you look at BaseTransformer:414 you have
>
> throw new TransformationException("Error copying source "
> + ObjectUtils.getObjectDescription(source) + "
> to destination "
> +
> ObjectUtils.getObjectDescription(destination), e);
>
> So the base exception is included in the TransformationException, and
> that is what usually will tell you what's going wrong. I'm not seeing
> the nested exception in the stack trace. Are you doing any type of
> exception catching in CopyUtil? That could be what is suppressing the
> full stack trace output.
>
> Matt
>
> Bruce Lombardi wrote:
>
> Matt,
>
>
>
>
>
> I have a few questions on Morph:
>
>
>
> 1. I know that if I need to translate from names on one bean to
> different names on another bean, I can supply a Map with the
> translations (e.g., in your example you translate "addresses" to
> "primaryAddress" by setting up a PropertyNameMappingCopier.) My
> question is: do you have to supply a Map with all the fields names to
> be copied, or only those that need to be translated to another name?
>
> 2. A related question. If I want to copy from one bean to
> another, but I only want to copy one or two fields, can I somehow
> supply the names of those fields and limit the copy to those? (maybe
> in a map like above, but with only the name of the fields to copy).
>
> 3. Finally, I am getting the following error when attempting to
> copy from one object to another. Each object has the following methods:
>
>
>
> public Map getLineItems();
>
> public void setLineItems(Map lineItems);
>
>
>
>
>
> SimpleDelegatingTransformer@11eb9b11 (class
> net.sf.morph.transform.transformers.SimpleDelegatingTransformer)
>
> [10/12/06 18:36:28:258 EDT] 00000037 MyPropertyNam I Copying
> properties lineItemData and lineItems
>
> [10/12/06 18:36:28:274 EDT] 00000037 MapReflector W The
> net.sf.morph.reflect.reflectors.MapReflector@7327db10 (class
> net.sf.morph.reflect.reflectors.MapReflector) is set to EXTRACT_VALUES
> so com.comcore.product.order.LineItemVO@13f05b11 (class
> com.comcore.product.order.LineItemVO) will be added to the Map with a
> null key
>
> [10/12/06 18:36:28:274 EDT] 00000037 SystemOut O I am here
>
> [10/12/06 18:36:28:274 EDT] 00000037 SystemErr R
> net.sf.morph.transform.TransformationException: Error copying source
> {1=com.comcore.product.order.LineItemVO@13f05b11,
> 2=com.comcore.product.order.LineItemVO@10935b11,
> 3=com.comcore.product.order.LineItemVO@10c81b11} (class
> java.util.Collections$SynchronizedMap) to destination
> {1=com.comcore.product.order.LineItemVO@fdc1b37,
> 2=com.comcore.product.order.LineItemVO@6ef5b37,
> 3=com.comcore.product.order.LineItemVO@6241b37} (class
> java.util.Collections$SynchronizedMap)
>
> at
> net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:414)
>
> at
> net.sf.morph.transform.transformers.SimpleDelegatingTransformer.copyImpl(SimpleDelegatingTransformer.java:201)
>
> at
> net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:407)
>
> at
> net.sf.morph.util.TransformerUtils.transform(TransformerUtils.java:163)
>
> at
> net.sf.morph.transform.copiers.BasePropertyNameCopier.copyProperty(BasePropertyNameCopier.java:122)
>
> at
> net.sf.morph.transform.copiers.PropertyNameMatchingCopier.copyImpl(PropertyNameMatchingCopier.java:91)
>
> at
> net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:407)
>
> at
> net.sf.morph.transform.transformers.SimpleDelegatingTransformer.copyImpl(SimpleDelegatingTransformer.java:201)
>
> at
> net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:407)
>
> at
> net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:429)
>
> at CopyUtil.copy(CopyUtil.java:64)
>
> at
> com.checkout.actions.ShoppingCartAction.processOutput(ShoppingCartAction.java:76)
>
>
>
>
>
>
>
>
>
|
|
From: Matt S. <Mat...@wh...> - 2006-02-10 19:13:02
|
I'm pleased to announce that Morph 1.0, the first production-quality
release of Morph is now available! Lots of us have been using Morph in
production for a long time, but finally with Morph 1.0 the API is stable
so you will be able to upgrade more easily to future versions of Morph.
Here are the changes in Morph 1.0:
* Improved Internationalization support for number to text and text
to number conversions
* Fixed bug that was causing Morph.convertToDouble and
Morph.convertToFloat to only return Integers
* Performanced tuned the static Morph conversion methods so that
they are nearly as fast as calling the corresponding conversion
method manually. For example, 10,000 iterations of
Morph.convertToString used to take 6 seconds on my PC compared to
only 50 milliseconds for NumberFormat.format. Now Morph only takes
around 200 milliseconds.
* Removed the BaseConverter and BaseCopier classes because they
didn't really do anything. Any existing classes that extend those
base classes should extend BaseTransformer instead. Just be sure
to |implements DecoratedConverter| to your converts and
|implements DecoratedConverter, DecoratedCopier| to your copiers.
* Minor updates to the reference documentation
* Added the ObjectToClassConverter and corresponding test case
Matt
|
|
From: Matt S. <sga...@li...> - 2005-12-13 14:37:23
|
Sorry it's been so long since the last Morph release, but I think you'll find the results were worth waiting for. Morph 0.9.2 fixes many bugs since the last release and introduced some API refinements that make the internal workings of the package easier to understand. Many thanks to Eduar Letifov who helped identify and fix some of the nastiest bugs in the previous release. The most major changes in this release are: - Removed the GraphTransformer interface and renamed the graphTransformer property of BaseTransformer back to nestedTransformer - Removed the TraverserConverter and refined the ContainerCopier so that it can convert to Iterators and Enumerators - Added TypeChangingGraphTransformer to assist with transformations of object graphs from a set of domain objects to a set of transfer objects - Various bug fixes |
|
From: chris <one...@gm...> - 2005-08-02 19:52:07
|
Ah, I see. Glad to hear it. I don't have a specific question right now. I started looking at Morph a long time ago, then got sidetracked. I might take a look again in the near future, so that's why I checked up on it and asked the question. Thanks On 8/2/05, Matt Sgarlata <mat...@ve...> wrote: > Quiet but alive :) Do you have a question? >=20 > Basically I haven't been working on the project much because it's > working well for me. I've found Morph 0.9 stable, performant and > well-suited for my needs. I haven't pushed for a 1.0 release because > I've been kind of lazy lately... hehe. >=20 > Matt >=20 > chris wrote: >=20 > >kinda quiet... > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >from IBM. Find simple to follow Roadmaps, straightforward articles, > >informative Webcasts and more! Get everything you need to get up to > >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick > >_______________________________________________ > >morph-user mailing list > >mor...@li... > >https://lists.sourceforge.net/lists/listinfo/morph-user > > > > > > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic= k > _______________________________________________ > morph-user mailing list > mor...@li... > https://lists.sourceforge.net/lists/listinfo/morph-user > |
|
From: Matt S. <mat...@ve...> - 2005-08-02 19:00:13
|
Quiet but alive :) Do you have a question? Basically I haven't been working on the project much because it's working well for me. I've found Morph 0.9 stable, performant and well-suited for my needs. I haven't pushed for a 1.0 release because I've been kind of lazy lately... hehe. Matt chris wrote: >kinda quiet... > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click >_______________________________________________ >morph-user mailing list >mor...@li... >https://lists.sourceforge.net/lists/listinfo/morph-user > > > |
|
From: chris <one...@gm...> - 2005-08-02 18:53:18
|
kinda quiet... |
|
From: <Mun...@cn...> - 2005-06-29 19:16:21
|
Hi, We are trying to see if we can use Morph where we have a requirement to pass context information from one layer to other layer (presentation to business). I looked at the documentation but it says to be done. Can somebody provide some examples or point me to some documentation on this thanks |
|
From: Matt S. <sga...@us...> - 2005-06-06 18:30:41
|
I'm glad you were able to get this worked out :)
Matt
Hernan Silberman wrote:
>In looking through the code, it does appear that the logging configuration is
>incorrect in my code, causing this call to toString(). Thanks for your previous
>message, it pointed me in the right direction and sorry for the list noise.
>
>Hernan
>
>On Mon, 6 Jun 2005, Hernan Silberman wrote:
>
>
>
>>Here's a stack trace. com.dw.nile.dom.SequenceDO is my source JavaBean that I'm
>>transforming with this call (myGraphTransformer is a
>>net.sf.morph.transform.transformers.DelegatingTransformer):
>>
>>myGraphTransformer.
>>convert( SequenceDescriptor.class,
>> theCurrSeq )
>>
>>at com.dw.nile.dom.SequenceDO.toString(SequenceDO.java:288)
>>at java.lang.String.valueOf(String.java:2577)
>>at java.lang.StringBuffer.append(StringBuffer.java:220)
>>at net.sf.morph.util.MorphUtils.getObjectDescription(MorphUtils.java:310)
>>at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:204)
>>at net.sf.morph.transform.transformers.DelegatingTransformer.convertImpl(DelegatingTransformer.java:180)
>>at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:225)
>>at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
>>
>>thanks Matt, let me know if you need more information or if you see something
>>I'm doing wrong.
>>
>>Hernan
>>
>>
>>On Mon, 6 Jun 2005, Matt Sgarlata wrote:
>>
>>
>>
>>>Hi Hernan,
>>>
>>>When is MorphUtil.getObjectDescription called? I think my intention was
>>>for it to only be called when writing TRACE output to the log file. As
>>>you point out, calling this method is incredibly expensive so in a
>>>production system it should definitely not be called.
>>>
>>>Matt
>>>
>>>Hernan Silberman wrote:
>>>
>>>
>>>
>>>>I've been doing lots of profiling today and I noticed that my JavaBeans involved
>>>>in Morph transformations are getting their toString() methods called.
>>>>
>>>>This happens in MorphUtil.getObjectDescription( Object object ). The else of
>>>>the MorphUtils.getObjectDescription() method looks like this:
>>>>
>>>>else {
>>>> return
>>>> getDelimiter(object) + object +
>>>> getDelimiter(object) + " (class " +
>>>> object.getClass().getName() + ")";
>>>>}
>>>>
>>>>This results in a call to String method:
>>>>
>>>>public static String valueOf(Object obj) {
>>>> return (obj == null) ? "null" : obj.toString();
>>>>}
>>>>
>>>>...which is where the toString() call on my objects is coming from.
>>>>
>>>>This is a fairly serious performance issue for me, because my toString()
>>>>methods are usually not very fast and intended for human eyes (the
>>>>java.lang.Object javadoc says "The result should be a concise but informative
>>>>representation that is easy for a person to read."). I have use cases that
>>>>routinely include Morphing hundreds of objects... times many possible threads,
>>>>every bit counts.
>>>>
>>>>Any way to avoid doing the toString() in MorphUtil.getObjectDescription()?
>>>>
>>>>I'm using Morph 0.8.3.
>>>>
>>>>many thanks!
>>>>Hernan
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
>>>>a projector? How fast can you ride your desk chair down the office luge track?
>>>>If you want to score the big prize, get to know the little guy.
>>>>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>>>_______________________________________________
>>>>morph-user mailing list
>>>>mor...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/morph-user
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
>>>a projector? How fast can you ride your desk chair down the office luge track?
>>>If you want to score the big prize, get to know the little guy.
>>>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>>_______________________________________________
>>>morph-user mailing list
>>>mor...@li...
>>>https://lists.sourceforge.net/lists/listinfo/morph-user
>>>
>>>
>>>
>>
>>
>
>
>
|
|
From: Hernan S. <hsi...@pd...> - 2005-06-06 18:04:29
|
In looking through the code, it does appear that the logging configuration is
incorrect in my code, causing this call to toString(). Thanks for your previous
message, it pointed me in the right direction and sorry for the list noise.
Hernan
On Mon, 6 Jun 2005, Hernan Silberman wrote:
>
> Here's a stack trace. com.dw.nile.dom.SequenceDO is my source JavaBean that I'm
> transforming with this call (myGraphTransformer is a
> net.sf.morph.transform.transformers.DelegatingTransformer):
>
> myGraphTransformer.
> convert( SequenceDescriptor.class,
> theCurrSeq )
>
> at com.dw.nile.dom.SequenceDO.toString(SequenceDO.java:288)
> at java.lang.String.valueOf(String.java:2577)
> at java.lang.StringBuffer.append(StringBuffer.java:220)
> at net.sf.morph.util.MorphUtils.getObjectDescription(MorphUtils.java:310)
> at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:204)
> at net.sf.morph.transform.transformers.DelegatingTransformer.convertImpl(DelegatingTransformer.java:180)
> at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:225)
> at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
>
> thanks Matt, let me know if you need more information or if you see something
> I'm doing wrong.
>
> Hernan
>
>
> On Mon, 6 Jun 2005, Matt Sgarlata wrote:
>
> > Hi Hernan,
> >
> > When is MorphUtil.getObjectDescription called? I think my intention was
> > for it to only be called when writing TRACE output to the log file. As
> > you point out, calling this method is incredibly expensive so in a
> > production system it should definitely not be called.
> >
> > Matt
> >
> > Hernan Silberman wrote:
> >
> > >I've been doing lots of profiling today and I noticed that my JavaBeans involved
> > >in Morph transformations are getting their toString() methods called.
> > >
> > >This happens in MorphUtil.getObjectDescription( Object object ). The else of
> > >the MorphUtils.getObjectDescription() method looks like this:
> > >
> > >else {
> > > return
> > > getDelimiter(object) + object +
> > > getDelimiter(object) + " (class " +
> > > object.getClass().getName() + ")";
> > >}
> > >
> > >This results in a call to String method:
> > >
> > >public static String valueOf(Object obj) {
> > > return (obj == null) ? "null" : obj.toString();
> > >}
> > >
> > >...which is where the toString() call on my objects is coming from.
> > >
> > >This is a fairly serious performance issue for me, because my toString()
> > >methods are usually not very fast and intended for human eyes (the
> > >java.lang.Object javadoc says "The result should be a concise but informative
> > >representation that is easy for a person to read."). I have use cases that
> > >routinely include Morphing hundreds of objects... times many possible threads,
> > >every bit counts.
> > >
> > >Any way to avoid doing the toString() in MorphUtil.getObjectDescription()?
> > >
> > >I'm using Morph 0.8.3.
> > >
> > >many thanks!
> > >Hernan
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
> > >a projector? How fast can you ride your desk chair down the office luge track?
> > >If you want to score the big prize, get to know the little guy.
> > >Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> > >_______________________________________________
> > >morph-user mailing list
> > >mor...@li...
> > >https://lists.sourceforge.net/lists/listinfo/morph-user
> > >
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
> > a projector? How fast can you ride your desk chair down the office luge track?
> > If you want to score the big prize, get to know the little guy.
> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> > _______________________________________________
> > morph-user mailing list
> > mor...@li...
> > https://lists.sourceforge.net/lists/listinfo/morph-user
> >
>
>
--
Hernan Silberman
PDI/Dreamworks
ext.29162 / 650-562-9162 / cell 415-810-5809
text pager: pag...@an...
|
|
From: Hernan S. <hsi...@pd...> - 2005-06-06 18:00:09
|
Here's a stack trace. com.dw.nile.dom.SequenceDO is my source JavaBean that I'm
transforming with this call (myGraphTransformer is a
net.sf.morph.transform.transformers.DelegatingTransformer):
myGraphTransformer.
convert( SequenceDescriptor.class,
theCurrSeq )
at com.dw.nile.dom.SequenceDO.toString(SequenceDO.java:288)
at java.lang.String.valueOf(String.java:2577)
at java.lang.StringBuffer.append(StringBuffer.java:220)
at net.sf.morph.util.MorphUtils.getObjectDescription(MorphUtils.java:310)
at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:204)
at net.sf.morph.transform.transformers.DelegatingTransformer.convertImpl(DelegatingTransformer.java:180)
at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:225)
at net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
thanks Matt, let me know if you need more information or if you see something
I'm doing wrong.
Hernan
On Mon, 6 Jun 2005, Matt Sgarlata wrote:
> Hi Hernan,
>
> When is MorphUtil.getObjectDescription called? I think my intention was
> for it to only be called when writing TRACE output to the log file. As
> you point out, calling this method is incredibly expensive so in a
> production system it should definitely not be called.
>
> Matt
>
> Hernan Silberman wrote:
>
> >I've been doing lots of profiling today and I noticed that my JavaBeans involved
> >in Morph transformations are getting their toString() methods called.
> >
> >This happens in MorphUtil.getObjectDescription( Object object ). The else of
> >the MorphUtils.getObjectDescription() method looks like this:
> >
> >else {
> > return
> > getDelimiter(object) + object +
> > getDelimiter(object) + " (class " +
> > object.getClass().getName() + ")";
> >}
> >
> >This results in a call to String method:
> >
> >public static String valueOf(Object obj) {
> > return (obj == null) ? "null" : obj.toString();
> >}
> >
> >...which is where the toString() call on my objects is coming from.
> >
> >This is a fairly serious performance issue for me, because my toString()
> >methods are usually not very fast and intended for human eyes (the
> >java.lang.Object javadoc says "The result should be a concise but informative
> >representation that is easy for a person to read."). I have use cases that
> >routinely include Morphing hundreds of objects... times many possible threads,
> >every bit counts.
> >
> >Any way to avoid doing the toString() in MorphUtil.getObjectDescription()?
> >
> >I'm using Morph 0.8.3.
> >
> >many thanks!
> >Hernan
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
> >a projector? How fast can you ride your desk chair down the office luge track?
> >If you want to score the big prize, get to know the little guy.
> >Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> >_______________________________________________
> >morph-user mailing list
> >mor...@li...
> >https://lists.sourceforge.net/lists/listinfo/morph-user
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> morph-user mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-user
>
--
Hernan Silberman
PDI/Dreamworks
ext.29162 / 650-562-9162 / cell 415-810-5809
text pager: pag...@an...
|
|
From: Matt S. <sga...@us...> - 2005-06-06 14:27:33
|
Hi Hernan,
When is MorphUtil.getObjectDescription called? I think my intention was
for it to only be called when writing TRACE output to the log file. As
you point out, calling this method is incredibly expensive so in a
production system it should definitely not be called.
Matt
Hernan Silberman wrote:
>I've been doing lots of profiling today and I noticed that my JavaBeans involved
>in Morph transformations are getting their toString() methods called.
>
>This happens in MorphUtil.getObjectDescription( Object object ). The else of
>the MorphUtils.getObjectDescription() method looks like this:
>
>else {
> return
> getDelimiter(object) + object +
> getDelimiter(object) + " (class " +
> object.getClass().getName() + ")";
>}
>
>This results in a call to String method:
>
>public static String valueOf(Object obj) {
> return (obj == null) ? "null" : obj.toString();
>}
>
>...which is where the toString() call on my objects is coming from.
>
>This is a fairly serious performance issue for me, because my toString()
>methods are usually not very fast and intended for human eyes (the
>java.lang.Object javadoc says "The result should be a concise but informative
>representation that is easy for a person to read."). I have use cases that
>routinely include Morphing hundreds of objects... times many possible threads,
>every bit counts.
>
>Any way to avoid doing the toString() in MorphUtil.getObjectDescription()?
>
>I'm using Morph 0.8.3.
>
>many thanks!
>Hernan
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
>a projector? How fast can you ride your desk chair down the office luge track?
>If you want to score the big prize, get to know the little guy.
>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>_______________________________________________
>morph-user mailing list
>mor...@li...
>https://lists.sourceforge.net/lists/listinfo/morph-user
>
>
>
|
|
From: Hernan S. <hsi...@pd...> - 2005-06-03 21:25:40
|
I've been doing lots of profiling today and I noticed that my JavaBeans involved
in Morph transformations are getting their toString() methods called.
This happens in MorphUtil.getObjectDescription( Object object ). The else of
the MorphUtils.getObjectDescription() method looks like this:
else {
return
getDelimiter(object) + object +
getDelimiter(object) + " (class " +
object.getClass().getName() + ")";
}
This results in a call to String method:
public static String valueOf(Object obj) {
return (obj == null) ? "null" : obj.toString();
}
...which is where the toString() call on my objects is coming from.
This is a fairly serious performance issue for me, because my toString()
methods are usually not very fast and intended for human eyes (the
java.lang.Object javadoc says "The result should be a concise but informative
representation that is easy for a person to read."). I have use cases that
routinely include Morphing hundreds of objects... times many possible threads,
every bit counts.
Any way to avoid doing the toString() in MorphUtil.getObjectDescription()?
I'm using Morph 0.8.3.
many thanks!
Hernan
|
|
From: Matt S. <sga...@us...> - 2005-04-27 14:25:44
|
Hi Nathan, I see what you're trying to do. I am hesitant to base the flag on whether a property is transient or not because properties in other objects which have properties (Maps, HttpRequest parameters, even ResultSet rows) do not have a notion of being transient or intransient. I see where you're going with this idea though, and I agree that the functionality would be handy to have out-of-the-box. Instead of basing the copy on whether the property is transient, how about we add a copyEmptyProperties boolean flag that indicates whether empty properties should be copied from the source to the destination. By default the flag would be set to true, as you suggested. If copyEmptyProperties was false, properties with 'empty' values like a null value or an empty string or empty collection would not be copied. I can code this into the next release, or if you'd like to see your name in the @author tag for the class and on the Contributors list of the Morph website, feel free to submit a patch :) I use Eclipse, so I'd prefer patches in the "Unified" format. Matt negge wrote: >Matt, > >Thanks for the quick response. Let me tell you how I'd like to use this >method. I am currently using Struts and have a set of Actions that let me >edit domain objects in a database. For each domain object, there is a >corresponding form bean that contains just accessor methods. The domain >objects are managed by hibernate, including the object relations - e.g., the >many-to-many relationship between a User object and an Organization object. > > > >The Problem > > >When I go to display the page containing the details for a particular User >object, I simply load the domain object via a DAO, and then do: > > User user=userDAO.load(userForm.getId()); > BeanUtils.copyProperties(userForm,user); > >Which copies everything over, including the collection that contains the >Organizations this user belongs to. > >When I bring up a page that allows you to modify the details of this user >(first name, last name, email address, etc. but *not* the organizations since >that is managed elsewhere) it uses the same userForm object. However, when I >go to submit this form and save the user, the organizations collection is >empty (since its not something to be edited). Hence > > User user=userDAO.load(userForm.getId()); > BeanUtils.copyProperties(user,userForm); > userDAO.save(user); > >just copies an empty collection over the existing one in the user object and >when I save it I've lost the organizations information. > > > >The Solution > > >What I'd like to be able to do is specify this collection as transient (which >I already do to support the EqualsBuilder, HashCodeBuilder, and >ToStringBuilder) . Then when simply change the code so that when viewing the >details of the object, you call: > > User user=userDAO.load(userForm.getId()); > BeanUtils.copyProperties(userForm,user,true); > >but when saving the details of the object you do: > > User user=userDAO.load(userForm.getId()); > BeanUtils.copyProperties(user,userForm,false); > userDAO.save(user); > >This would allow me to only have you editing the fields that make sense (those >which are not relationships). > > >I hope this makes sense to you. I am not familiar enough with the morph >library to have presented the problem using your API, please excuse me. I >like your idea of implementing it as a subclass, but strongly believe this is >something you should support out of the box. As in, the default >implementation of copy(A,B) should call copy(A,B,true). > >I'd be happy to help out with implementing this in any way I can. I submitted >a bug to the BeanUtils issue tracker for the same feature and doubt they will >ever get to it. > > >Nathan > > > > >>===== Original Message From Matt Sgarlata <sga...@us...> >> >> >===== > > >>Hi Nathan, >> >>Thanks for evaluating Morph! >> >>A boolean flag in the PropertyNameMatchingCopier indicating whether >>transiesnt properties should be copied is an interesting idea. Would >>you mind describing how you would use such a property? >> >>Morph does not distinguish transient from non-transient properties or >>static from non-static properties. The main reason for this is that >>these notions don't make sense when you start treating other objects >>such as Maps and HTTP request parameters the same way as you treat >>Objects. Maps and HTTP request parameters don't have any notion of >>transient or static properties. >> >>I think the easiest way to accomodate your requirement would be to add a >>getPropertiesToCopy(Object destination, Object source) method to the >>PropertyNameMatchingCopier that by default delegated to >>getPropertiesToCopy(). That way, in a subclass you could override the >>getPropertiesToCopy method and scan the source object to determine which >>properties are transient. Alternatively, if you're only dealing with a >>couple transformations you could just specify the propertiesToCopy >>statically by calling the setPropertiesToCopy method. I will definitely >>be adding the getPropertiesToCopy(Object destination, Object source) >>method in the next version of Morph. If you like, I can do a release >>for you soon that includes this method. >> >>Matt >> >>negge wrote: >> >> >> >>>Matt, >>> >>>I was just experiencing some frustration with BeanUtils and thought I'd take >>> >>> >a > > >>>look at the Morph package. I was hoping the PropertyNameMatchingCopier had >>>the ability to allow you to specify a boolean indicating whether or not it >>>should copy member variables that are marked as transient. This >>> >>> >functionality > > >>>exists in the EqualsBuilder, HashCodeBuilder, ToStringBuilder so you can >>> >>> >mark > > >>>primary keys or Collection objects as transient and they will not be used in >>>computing the hashcode or equality of two objects. >>> >>>I'd hope to see it implemented so I could just execute >>> >>> copy(user,userForm,false); >>> >>>and have it work. >>> >>>Thanks for creating a very useful looking library. >>> >>>Nathan >>> >>> >>> >>> >>> >>>>===== Original Message From Matt Sgarlata <sga...@us...> >>>> >>>> >>>> >>>> >>>===== >>> >>> >>> >>> >>>>Hi Nathan, >>>> >>>>I noticed the patch you submitted to BeanUtils. If you're anything like >>>>me, you're starting to reach the point of frustration with the package. >>>>I discovered that as long as I did exactly what BeanUtils was designed >>>>to do, I didn't run into any problems. However, as soon as I tried to >>>>customize things for my application I ran into serious problems. >>>> >>>>This led me to create a similar framework that is much more configurable >>>>and flexible than BeanUtils. I encourage you to check it out at >>>>morph.sourceforge.net. It is in late beta and already offers pretty >>>>much all of the features of BeanUtils. Hopefully it can help you solve >>>>some of your problems! >>>> >>>>Matt >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> > > > > > |
|
From: negge <ne...@vt...> - 2005-04-27 13:17:57
|
Matt, Thanks for the quick response. Let me tell you how I'd like to use this method. I am currently using Struts and have a set of Actions that let me edit domain objects in a database. For each domain object, there is a corresponding form bean that contains just accessor methods. The domain objects are managed by hibernate, including the object relations - e.g., the many-to-many relationship between a User object and an Organization object. The Problem When I go to display the page containing the details for a particular User object, I simply load the domain object via a DAO, and then do: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(userForm,user); Which copies everything over, including the collection that contains the Organizations this user belongs to. When I bring up a page that allows you to modify the details of this user (first name, last name, email address, etc. but *not* the organizations since that is managed elsewhere) it uses the same userForm object. However, when I go to submit this form and save the user, the organizations collection is empty (since its not something to be edited). Hence User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(user,userForm); userDAO.save(user); just copies an empty collection over the existing one in the user object and when I save it I've lost the organizations information. The Solution What I'd like to be able to do is specify this collection as transient (which I already do to support the EqualsBuilder, HashCodeBuilder, and ToStringBuilder) . Then when simply change the code so that when viewing the details of the object, you call: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(userForm,user,true); but when saving the details of the object you do: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(user,userForm,false); userDAO.save(user); This would allow me to only have you editing the fields that make sense (those which are not relationships). I hope this makes sense to you. I am not familiar enough with the morph library to have presented the problem using your API, please excuse me. I like your idea of implementing it as a subclass, but strongly believe this is something you should support out of the box. As in, the default implementation of copy(A,B) should call copy(A,B,true). I'd be happy to help out with implementing this in any way I can. I submitted a bug to the BeanUtils issue tracker for the same feature and doubt they will ever get to it. Nathan >===== Original Message From Matt Sgarlata <sga...@us...> ===== >Hi Nathan, > >Thanks for evaluating Morph! > >A boolean flag in the PropertyNameMatchingCopier indicating whether >transiesnt properties should be copied is an interesting idea. Would >you mind describing how you would use such a property? > >Morph does not distinguish transient from non-transient properties or >static from non-static properties. The main reason for this is that >these notions don't make sense when you start treating other objects >such as Maps and HTTP request parameters the same way as you treat >Objects. Maps and HTTP request parameters don't have any notion of >transient or static properties. > >I think the easiest way to accomodate your requirement would be to add a >getPropertiesToCopy(Object destination, Object source) method to the >PropertyNameMatchingCopier that by default delegated to >getPropertiesToCopy(). That way, in a subclass you could override the >getPropertiesToCopy method and scan the source object to determine which >properties are transient. Alternatively, if you're only dealing with a >couple transformations you could just specify the propertiesToCopy >statically by calling the setPropertiesToCopy method. I will definitely >be adding the getPropertiesToCopy(Object destination, Object source) >method in the next version of Morph. If you like, I can do a release >for you soon that includes this method. > >Matt > >negge wrote: > >>Matt, >> >>I was just experiencing some frustration with BeanUtils and thought I'd take a >>look at the Morph package. I was hoping the PropertyNameMatchingCopier had >>the ability to allow you to specify a boolean indicating whether or not it >>should copy member variables that are marked as transient. This functionality >>exists in the EqualsBuilder, HashCodeBuilder, ToStringBuilder so you can mark >>primary keys or Collection objects as transient and they will not be used in >>computing the hashcode or equality of two objects. >> >>I'd hope to see it implemented so I could just execute >> >> copy(user,userForm,false); >> >>and have it work. >> >>Thanks for creating a very useful looking library. >> >>Nathan >> >> >> >>>===== Original Message From Matt Sgarlata <sga...@us...> >>> >>> >>===== >> >> >>>Hi Nathan, >>> >>>I noticed the patch you submitted to BeanUtils. If you're anything like >>>me, you're starting to reach the point of frustration with the package. >>>I discovered that as long as I did exactly what BeanUtils was designed >>>to do, I didn't run into any problems. However, as soon as I tried to >>>customize things for my application I ran into serious problems. >>> >>>This led me to create a similar framework that is much more configurable >>>and flexible than BeanUtils. I encourage you to check it out at >>>morph.sourceforge.net. It is in late beta and already offers pretty >>>much all of the features of BeanUtils. Hopefully it can help you solve >>>some of your problems! >>> >>>Matt >>> >>> >> >> >> >> >> |
|
From: Matt S. <sga...@us...> - 2005-04-26 18:59:39
|
Hi Nathan, Thanks for evaluating Morph! A boolean flag in the PropertyNameMatchingCopier indicating whether transiesnt properties should be copied is an interesting idea. Would you mind describing how you would use such a property? Morph does not distinguish transient from non-transient properties or static from non-static properties. The main reason for this is that these notions don't make sense when you start treating other objects such as Maps and HTTP request parameters the same way as you treat Objects. Maps and HTTP request parameters don't have any notion of transient or static properties. I think the easiest way to accomodate your requirement would be to add a getPropertiesToCopy(Object destination, Object source) method to the PropertyNameMatchingCopier that by default delegated to getPropertiesToCopy(). That way, in a subclass you could override the getPropertiesToCopy method and scan the source object to determine which properties are transient. Alternatively, if you're only dealing with a couple transformations you could just specify the propertiesToCopy statically by calling the setPropertiesToCopy method. I will definitely be adding the getPropertiesToCopy(Object destination, Object source) method in the next version of Morph. If you like, I can do a release for you soon that includes this method. Matt negge wrote: >Matt, > >I was just experiencing some frustration with BeanUtils and thought I'd take a >look at the Morph package. I was hoping the PropertyNameMatchingCopier had >the ability to allow you to specify a boolean indicating whether or not it >should copy member variables that are marked as transient. This functionality >exists in the EqualsBuilder, HashCodeBuilder, ToStringBuilder so you can mark >primary keys or Collection objects as transient and they will not be used in >computing the hashcode or equality of two objects. > >I'd hope to see it implemented so I could just execute > > copy(user,userForm,false); > >and have it work. > >Thanks for creating a very useful looking library. > >Nathan > > > >>===== Original Message From Matt Sgarlata <sga...@us...> >> >> >===== > > >>Hi Nathan, >> >>I noticed the patch you submitted to BeanUtils. If you're anything like >>me, you're starting to reach the point of frustration with the package. >>I discovered that as long as I did exactly what BeanUtils was designed >>to do, I didn't run into any problems. However, as soon as I tried to >>customize things for my application I ran into serious problems. >> >>This led me to create a similar framework that is much more configurable >>and flexible than BeanUtils. I encourage you to check it out at >>morph.sourceforge.net. It is in late beta and already offers pretty >>much all of the features of BeanUtils. Hopefully it can help you solve >>some of your problems! >> >>Matt >> >> > > > > > |
|
From: Matt S. <sga...@us...> - 2005-04-15 15:58:16
|
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
|
|
From: Matt S. <sga...@us...> - 2005-04-04 21:04:15
|
Hi Matt, thanks for using Morph! The PropertyNameMappingCopier is always getting picked up because by default the copier specifies that it can copy any object to any other object. You're probably putting in your PropertyNameMappingCopier first and your ContainerCopier second. This will cause the PNMC to always kick in. There are two simple solutions you can try, both of which should work: - Make the PNMC class less "greedy" so that it only tries to transform some types of objects. You can do this by modifying the sourceClasses and destinationClasses properties. - When you configure the DelegatingTransformer, use the CC first and the PNMC second so that the when a collection is encountered, the CC kicks in before the greedy PNMC tries to perform the transformation. Either one of those should work, but if you keep having trouble don't hesitate to post a follow-up question! Matt Matthieu Riou wrote: >Hi, > >I have a simple graph of object with AClass objects having collections >of BClass instances. I tried many solutions to get this transformed to >A2Class with a collection of B2Class but couldn't get anything >working. I want both the properties of A and B instances to be copied >to A2 and B2 but also the Collection to be processed automatically. > >My hunch had been to stuff both my PropertyNameMappingCopiers and a >CollectionCopier in the DelegatingTransformer components but the >PropertyNameMappingCopiers always get picked up first so the >collections are never processed. > >How should I proceed to get my object converted properly? > >Thanks, > >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_id=6595&alloc_id=14396&op=click >_______________________________________________ >morph-user mailing list >mor...@li... >https://lists.sourceforge.net/lists/listinfo/morph-user > > > |
|
From: Matthieu R. <mat...@gm...> - 2005-04-04 08:00:45
|
Hi, I have a simple graph of object with AClass objects having collections of BClass instances. I tried many solutions to get this transformed to A2Class with a collection of B2Class but couldn't get anything working. I want both the properties of A and B instances to be copied to A2 and B2 but also the Collection to be processed automatically. My hunch had been to stuff both my PropertyNameMappingCopiers and a CollectionCopier in the DelegatingTransformer components but the PropertyNameMappingCopiers always get picked up first so the collections are never processed. How should I proceed to get my object converted properly? Thanks, Matt. |
|
From: Hernan S. <hsi...@pd...> - 2005-03-09 18:39:04
|
Clever workaround, it worked and will be fine in the short term on the project
I'm working on.
Thanks... Hernan
On Wed, 9 Mar 2005, Matt Sgarlata wrote:
> Hi Hernan,
>
> I think the problem is probably that the components property of the
> DelegatingTransformer is of type Component[], so when Spring populates
> the property, it create an array with runtime type Component[]. The
> DelegatingTransformer is expecting a runtime type of Transformer[].
> This would explain why you can setup your transformer programmatically
> but not using Spring.
>
> I guess the easiest quick fix would probably be for you to subclass the
> DelegatingTransformer and expose a Transformer[] setTransformers method
> so that Spring creates an array with the correct runtime type. Long
> term, I'm planning on replacing the components property with a Map of
> String transformer names to Transformer objects. This will make it
> easier to work with the DelegatingTransformer programmatically if you
> want to, for example, replace only a single transformer.
>
> Does this short-term fix work for you?
>
> Matt
>
> Hernan Silberman wrote:
>
> >I failed to mention:
> >
> >I'm using Morph 0.8.3
> >
> >thnx...
> >hernan
> >
> >---------- Forwarded message ----------
> >Date: Tue, 8 Mar 2005 14:55:57 -0800 (PST)
> >From: Hernan Silberman <hsi...@pd...>
> >To: mor...@li...
> >Subject: ClassCastException...
> >
> >
> >I'm sure I'm doing something wrong here... I'm trying to build a graph
> >transformer using a simple Spring context that defines this bean:
> >
> ><bean
> > id="graphTransformer"
> > class="net.sf.morph.transform.transformers.DelegatingTransformer">
> > <property name="components">
> > <list>
> > <ref bean="immutableTypesOnlyIdentityConverter"/>
> > <ref bean="timeCopier"/>
> > <ref bean="collectionCopier"/>
> > <ref bean="propertyNameMatchingCopier"/>
> > <ref bean="containerCopier"/>
> > </list>
> > </property>
> ></bean>
> >
> >
> >All of the reference beans are very simple bean definitions, for example:
> >
> ><bean
> > name="collectionCopier"
> > class="net.sf.morph.transform.copiers.CollectionCopier"/>
> >
> >The context loads up fine as a FileSystemXmlApplicationContext. When I
> >try to do the following simple conversion in my Test case:
> >
> >public void testSimpleConvert()
> >{
> > String theSource = new String("Hello");
> > String theDest =
> > (String)myGraphTransformer.convert( String.class, theSource );
> > assertNotNull(theDest);
> > assertEquals(theSource,theDest);
> >}
> >
> >...I get the exception below. I don't get this exception when I build this
> >DepegatingTransformer programmatically. Also, I don't get the exception
> >when I leave off the "components" property definition for the graphTransformer
> >bean. I can see DelegatingTransformer is doing a case to Transformer[] which is
> >failing.
> >
> >Please let me know if you spot my error... thanks in advance... Hernan
> >
> >
> >net.sf.morph.transform.TransformationException: Could not initialize transformer
> >net.sf.morph.transform.transformers.DelegatingTransformer@e6f7d2 (class
> >net.sf.morph.transform.transformers.DelegatingTransformer)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:193)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.getDestinationClasses(BaseTransformer.java:149)
> > at
> >net.sf.morph.util.TransformerUtils.isImplicitlyTransformable(TransformerUtils.java:53)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.isTransformable(BaseTransformer.java:105)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:216)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
> > at
> >tests.morph.MorphContextTest.testSimpleConvert(MorphContextTest.java:59)
> >...(Click for full stack trace)...
> >Caused by: java.lang.ClassCastException
> > at
> >net.sf.morph.transform.transformers.DelegatingTransformer.getTransformers(DelegatingTransformer.java:260)
> > at
> >net.sf.morph.transform.transformers.DelegatingTransformer.getSourceClassesImpl(DelegatingTransformer.java:136)
> > at
> >net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:171)
> > ... 21 more
> >
> >
> >
> >
> >-------------------------------------------------------
> >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
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> 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
>
--
Hernan Silberman
PDI/Dreamworks
ext.29162 / 650-562-9162 / cell 415-810-5809
text pager: pag...@an...
|
|
From: Matt S. <sga...@us...> - 2005-03-09 15:36:48
|
Hi Hernan,
I think the problem is probably that the components property of the
DelegatingTransformer is of type Component[], so when Spring populates
the property, it create an array with runtime type Component[]. The
DelegatingTransformer is expecting a runtime type of Transformer[].
This would explain why you can setup your transformer programmatically
but not using Spring.
I guess the easiest quick fix would probably be for you to subclass the
DelegatingTransformer and expose a Transformer[] setTransformers method
so that Spring creates an array with the correct runtime type. Long
term, I'm planning on replacing the components property with a Map of
String transformer names to Transformer objects. This will make it
easier to work with the DelegatingTransformer programmatically if you
want to, for example, replace only a single transformer.
Does this short-term fix work for you?
Matt
Hernan Silberman wrote:
>I failed to mention:
>
>I'm using Morph 0.8.3
>
>thnx...
>hernan
>
>---------- Forwarded message ----------
>Date: Tue, 8 Mar 2005 14:55:57 -0800 (PST)
>From: Hernan Silberman <hsi...@pd...>
>To: mor...@li...
>Subject: ClassCastException...
>
>
>I'm sure I'm doing something wrong here... I'm trying to build a graph
>transformer using a simple Spring context that defines this bean:
>
><bean
> id="graphTransformer"
> class="net.sf.morph.transform.transformers.DelegatingTransformer">
> <property name="components">
> <list>
> <ref bean="immutableTypesOnlyIdentityConverter"/>
> <ref bean="timeCopier"/>
> <ref bean="collectionCopier"/>
> <ref bean="propertyNameMatchingCopier"/>
> <ref bean="containerCopier"/>
> </list>
> </property>
></bean>
>
>
>All of the reference beans are very simple bean definitions, for example:
>
><bean
> name="collectionCopier"
> class="net.sf.morph.transform.copiers.CollectionCopier"/>
>
>The context loads up fine as a FileSystemXmlApplicationContext. When I
>try to do the following simple conversion in my Test case:
>
>public void testSimpleConvert()
>{
> String theSource = new String("Hello");
> String theDest =
> (String)myGraphTransformer.convert( String.class, theSource );
> assertNotNull(theDest);
> assertEquals(theSource,theDest);
>}
>
>...I get the exception below. I don't get this exception when I build this
>DepegatingTransformer programmatically. Also, I don't get the exception
>when I leave off the "components" property definition for the graphTransformer
>bean. I can see DelegatingTransformer is doing a case to Transformer[] which is
>failing.
>
>Please let me know if you spot my error... thanks in advance... Hernan
>
>
>net.sf.morph.transform.TransformationException: Could not initialize transformer
>net.sf.morph.transform.transformers.DelegatingTransformer@e6f7d2 (class
>net.sf.morph.transform.transformers.DelegatingTransformer)
> at
>net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:193)
> at
>net.sf.morph.transform.transformers.BaseTransformer.getDestinationClasses(BaseTransformer.java:149)
> at
>net.sf.morph.util.TransformerUtils.isImplicitlyTransformable(TransformerUtils.java:53)
> at
>net.sf.morph.transform.transformers.BaseTransformer.isTransformable(BaseTransformer.java:105)
> at
>net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:216)
> at
>net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
> at
>tests.morph.MorphContextTest.testSimpleConvert(MorphContextTest.java:59)
>...(Click for full stack trace)...
>Caused by: java.lang.ClassCastException
> at
>net.sf.morph.transform.transformers.DelegatingTransformer.getTransformers(DelegatingTransformer.java:260)
> at
>net.sf.morph.transform.transformers.DelegatingTransformer.getSourceClassesImpl(DelegatingTransformer.java:136)
> at
>net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:171)
> ... 21 more
>
>
>
>
>-------------------------------------------------------
>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
>
>
>
|
|
From: Hernan S. <hsi...@pd...> - 2005-03-08 22:57:13
|
I failed to mention:
I'm using Morph 0.8.3
thnx...
hernan
---------- Forwarded message ----------
Date: Tue, 8 Mar 2005 14:55:57 -0800 (PST)
From: Hernan Silberman <hsi...@pd...>
To: mor...@li...
Subject: ClassCastException...
I'm sure I'm doing something wrong here... I'm trying to build a graph
transformer using a simple Spring context that defines this bean:
<bean
id="graphTransformer"
class="net.sf.morph.transform.transformers.DelegatingTransformer">
<property name="components">
<list>
<ref bean="immutableTypesOnlyIdentityConverter"/>
<ref bean="timeCopier"/>
<ref bean="collectionCopier"/>
<ref bean="propertyNameMatchingCopier"/>
<ref bean="containerCopier"/>
</list>
</property>
</bean>
All of the reference beans are very simple bean definitions, for example:
<bean
name="collectionCopier"
class="net.sf.morph.transform.copiers.CollectionCopier"/>
The context loads up fine as a FileSystemXmlApplicationContext. When I
try to do the following simple conversion in my Test case:
public void testSimpleConvert()
{
String theSource = new String("Hello");
String theDest =
(String)myGraphTransformer.convert( String.class, theSource );
assertNotNull(theDest);
assertEquals(theSource,theDest);
}
...I get the exception below. I don't get this exception when I build this
DepegatingTransformer programmatically. Also, I don't get the exception
when I leave off the "components" property definition for the graphTransformer
bean. I can see DelegatingTransformer is doing a case to Transformer[] which is
failing.
Please let me know if you spot my error... thanks in advance... Hernan
net.sf.morph.transform.TransformationException: Could not initialize transformer
net.sf.morph.transform.transformers.DelegatingTransformer@e6f7d2 (class
net.sf.morph.transform.transformers.DelegatingTransformer)
at
net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:193)
at
net.sf.morph.transform.transformers.BaseTransformer.getDestinationClasses(BaseTransformer.java:149)
at
net.sf.morph.util.TransformerUtils.isImplicitlyTransformable(TransformerUtils.java:53)
at
net.sf.morph.transform.transformers.BaseTransformer.isTransformable(BaseTransformer.java:105)
at
net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:216)
at
net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
at
tests.morph.MorphContextTest.testSimpleConvert(MorphContextTest.java:59)
...(Click for full stack trace)...
Caused by: java.lang.ClassCastException
at
net.sf.morph.transform.transformers.DelegatingTransformer.getTransformers(DelegatingTransformer.java:260)
at
net.sf.morph.transform.transformers.DelegatingTransformer.getSourceClassesImpl(DelegatingTransformer.java:136)
at
net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:171)
... 21 more
|
|
From: Hernan S. <hsi...@pd...> - 2005-03-08 22:56:07
|
I'm sure I'm doing something wrong here... I'm trying to build a graph
transformer using a simple Spring context that defines this bean:
<bean
id="graphTransformer"
class="net.sf.morph.transform.transformers.DelegatingTransformer">
<property name="components">
<list>
<ref bean="immutableTypesOnlyIdentityConverter"/>
<ref bean="timeCopier"/>
<ref bean="collectionCopier"/>
<ref bean="propertyNameMatchingCopier"/>
<ref bean="containerCopier"/>
</list>
</property>
</bean>
All of the reference beans are very simple bean definitions, for example:
<bean
name="collectionCopier"
class="net.sf.morph.transform.copiers.CollectionCopier"/>
The context loads up fine as a FileSystemXmlApplicationContext. When I
try to do the following simple conversion in my Test case:
public void testSimpleConvert()
{
String theSource = new String("Hello");
String theDest =
(String)myGraphTransformer.convert( String.class, theSource );
assertNotNull(theDest);
assertEquals(theSource,theDest);
}
...I get the exception below. I don't get this exception when I build this
DepegatingTransformer programmatically. Also, I don't get the exception
when I leave off the "components" property definition for the graphTransformer
bean. I can see DelegatingTransformer is doing a case to Transformer[] which is
failing.
Please let me know if you spot my error... thanks in advance... Hernan
net.sf.morph.transform.TransformationException: Could not initialize transformer
net.sf.morph.transform.transformers.DelegatingTransformer@e6f7d2 (class
net.sf.morph.transform.transformers.DelegatingTransformer)
at
net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:193)
at
net.sf.morph.transform.transformers.BaseTransformer.getDestinationClasses(BaseTransformer.java:149)
at
net.sf.morph.util.TransformerUtils.isImplicitlyTransformable(TransformerUtils.java:53)
at
net.sf.morph.transform.transformers.BaseTransformer.isTransformable(BaseTransformer.java:105)
at
net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:216)
at
net.sf.morph.transform.transformers.BaseTransformer.convert(BaseTransformer.java:237)
at
tests.morph.MorphContextTest.testSimpleConvert(MorphContextTest.java:59)
...(Click for full stack trace)...
Caused by: java.lang.ClassCastException
at
net.sf.morph.transform.transformers.DelegatingTransformer.getTransformers(DelegatingTransformer.java:260)
at
net.sf.morph.transform.transformers.DelegatingTransformer.getSourceClassesImpl(DelegatingTransformer.java:136)
at
net.sf.morph.transform.transformers.BaseTransformer.initialize(BaseTransformer.java:171)
... 21 more
|
|
From: Matt S. <mat...@sp...> - 2005-03-06 19:53:32
|
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
|
|
From: Matt S. <sga...@us...> - 2005-03-03 17:50:01
|
Hello again Hernan, I just took a look at the code that's in Morph 0.8.2, and the ContainerCopier should detect you are converting to a ChildDTO[] array and automatically do the conversion from a List or array of ChildDO objects. It will delegate to the converter you specify as the nestedTransformer (that is a protected property of the underlying BaseTransformer that is made public in the ContainerCopier). In Morph 0.8.3, which I will release this weekend, that property has been renamed graphTransformer. Also, in Morph 0.8.3 if you want to use an untyped collection, you can force a transformation to nested ChildDTO objects in your collection by populating the containedSourceToDestinationMapping property of the CollectionCopier. As I mentioned in a previous post, I'll release Morph 0.8.3 this weekend :) Matt Hernan Silberman wrote: >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 >>> >>> > > > >------------------------------------------------------- >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 > > > |
|
From: Matt S. <mat...@ve...> - 2005-03-03 14:50:43
|
Hi Matthieu, The current build of Morph will enter an infinite loop when either cycles or bidirectional associations are present in the object graph. Morph treats these two types of relationships as essentially the same thing. I'll definitely get a release out this weekend :) Matt Matthieu Riou wrote: >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. > > >------------------------------------------------------- >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 > > > |
2 messages has been excluded from this view by a project administrator.
