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

Re: [morph-developer] releases

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> > Well, we've been quiet lately.  :)
> It certainly has!
> 
> I added you as an admin for Composite.  I also
> looked over your checkins 
> (which look great, as always) and checked in a
> revised 
> BeanToPrettyTextConverter and another minor change
> or two.  One thing I 
> was wondering is could we come up with a better name
> for the 
> TextConverter.emptyNull property?  Perhaps
> treatEmptyTextAsNull would be 
> more descriptive?

Yeah, something like that would probably be better. 
I'll be sure to address that.

> 
> For doing a release, there are 3 things to do (that
> I can think of, 
> anyway!):
> 1) Do the actual release through the SF system. 
> This used to involve 
> uploading the file to an anonymous FTP site but I'm
> not really sure anymore.
> 2) Update the website (optional).  To do this, I
> FTP'd a ZIP of the 
> website to SF servers using some secure FTP program
> (no, a regular 
> program won't do!).  Next using some secure
> telnet-like program navigate 
> to the appropriate directory and explode the ZIP
> 3) Email the morph-dev, morph-user and
> morph-announce
> 

Doesn't sound too bad.  :)

-Matt B

> Matt S
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 



       
____________________________________________________________________________________Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

Re: [morph-developer] releases

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> Well, we've been quiet lately.  :)
It certainly has!

I added you as an admin for Composite.  I also looked over your checkins 
(which look great, as always) and checked in a revised 
BeanToPrettyTextConverter and another minor change or two.  One thing I 
was wondering is could we come up with a better name for the 
TextConverter.emptyNull property?  Perhaps treatEmptyTextAsNull would be 
more descriptive?

For doing a release, there are 3 things to do (that I can think of, 
anyway!):
1) Do the actual release through the SF system.  This used to involve 
uploading the file to an anonymous FTP site but I'm not really sure anymore.
2) Update the website (optional).  To do this, I FTP'd a ZIP of the 
website to SF servers using some secure FTP program (no, a regular 
program won't do!).  Next using some secure telnet-like program navigate 
to the appropriate directory and explode the ZIP
3) Email the morph-dev, morph-user and morph-announce

Matt S

[morph-developer] releases

[Matt B. <gud...@ya...>]

Well, we've been quiet lately.  :)  I have been
developing feverishly against Morph HEAD and like to
think that the fact that my commits have stopped over
the past few weeks means it's getting pretty stable
overall.  I'd like to go ahead and cut a 1.0.1 release
of the composite project as that should be low-hanging
fruit, and use that to come up to speed on the release
process before attempting to release Morph 1.0.2,
which depends on Composite 1.0.1 anyway.  I'd like to
get both releases into the maven2 rep and all that
goodness.  Meanwhile we wait for the smoke to clear at
Apache wrt the future of Jakarta commons and our
planned incubation.  :)

My holdup is I need to be added to Composite on sf,
probably as an admin I'm guessing?

br,
Matt (B)


       
____________________________________________________________________________________Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

Re: [morph-developer] Integration with other packages WAS Re: Spring support

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I think either way is fine.
> 
> The advantage to putting it in integration.commons
> would be that 
> breaking Morph into several smaller JARs (like
> Spring does) at some 
> point down the road would be much easier.  For
> example:
> morph-core.jar
> morph-reflect.jar
> morph-transform.jar
> morph-context.jar
> morph-lang.jar
> morph-wrap.jar
> morph-commons.jar
> morph-beanutils.jar
> 
> It would also allow us to more easily isolate code
> that has certain 
> dependencies in the build script if, for example, we
> decided not to 
> bundle commons-collections in the binary download
> (actually you may 
> already be leaning this way with Ivy, IDK...)  I
> know if we go to a new 
> integration package there are lots of things we'll
> need to move, but it 
> shouldn't be too bad.
> 
> The only thing I really care about is that we only
> have compile time 
> dependencies on things like commons-collections.  I
> consider Morph to be 
> a very very low level tool (at least the Reflector)
> part, and I don't 
> want it to have any required dependencies other than
> commons-logging.
> 

This is what Ivy buys you with what it calls
"configurations."  A user can declare a dependency on
Ivy in "foo" configuration and Ivy will retrieve only
the dependencies for that configuration.  So the build
configuration has many more dependencies than
"default".

-Matt B

> Matt
> 
> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> I like net.sf.morph.integration.spring.
> >>     
> >
> > I think this was a fine end to that discussion wrt
> > classes intended to facilitate use with other
> > libraries.  But what about, to give a concrete
> > example, such a class as an adapter to allow the
> use
> > of a commons-collections Transformer as a Morph
> > DecoratedConverter?  I was leaning towards
> >
>
net.sf.morph.integration.commons.CommonsCollectionsTransformerAdapter
> > but since it is a converter maybe it wants to live
> in
> > net.sf.morph.transform.converters or
> > net.sf.morph.transform.converters.ext ?  Opinion?
> >
> > -Matt B
> >
> > [SNIP]
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Integration with other packages WAS Re: Spring support

[Matt S. <Mat...@wh...>]

I think either way is fine.

The advantage to putting it in integration.commons would be that 
breaking Morph into several smaller JARs (like Spring does) at some 
point down the road would be much easier.  For example:
morph-core.jar
morph-reflect.jar
morph-transform.jar
morph-context.jar
morph-lang.jar
morph-wrap.jar
morph-commons.jar
morph-beanutils.jar

It would also allow us to more easily isolate code that has certain 
dependencies in the build script if, for example, we decided not to 
bundle commons-collections in the binary download (actually you may 
already be leaning this way with Ivy, IDK...)  I know if we go to a new 
integration package there are lots of things we'll need to move, but it 
shouldn't be too bad.

The only thing I really care about is that we only have compile time 
dependencies on things like commons-collections.  I consider Morph to be 
a very very low level tool (at least the Reflector) part, and I don't 
want it to have any required dependencies other than commons-logging.

Matt

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> I like net.sf.morph.integration.spring.
>>     
>
> I think this was a fine end to that discussion wrt
> classes intended to facilitate use with other
> libraries.  But what about, to give a concrete
> example, such a class as an adapter to allow the use
> of a commons-collections Transformer as a Morph
> DecoratedConverter?  I was leaning towards
> net.sf.morph.integration.commons.CommonsCollectionsTransformerAdapter
> but since it is a converter maybe it wants to live in
> net.sf.morph.transform.converters or
> net.sf.morph.transform.converters.ext ?  Opinion?
>
> -Matt B
>
> [SNIP]
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>   

[morph-developer] Integration with other packages WAS Re: Spring support

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I like net.sf.morph.integration.spring.

I think this was a fine end to that discussion wrt
classes intended to facilitate use with other
libraries.  But what about, to give a concrete
example, such a class as an adapter to allow the use
of a commons-collections Transformer as a Morph
DecoratedConverter?  I was leaning towards
net.sf.morph.integration.commons.CommonsCollectionsTransformerAdapter
but since it is a converter maybe it wants to live in
net.sf.morph.transform.converters or
net.sf.morph.transform.converters.ext ?  Opinion?

-Matt B

[SNIP]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I think for almost all transformers where source and
> destination classes 
> are not static we should make the mutators public. 
> So: 
> ChainedConverter, ConverterDecorator,
> CopierDecorator, CumulativeCopier, 
> AssemblerCopier, MultipleDestinationConverter.  I
> don't think they need 
> to be public on SimpleDelegatingTransformer.

More on this:

  ChainedConverter is now ChainedTransformer as it can
copy if the last component is a Copier--or would that
then be ChainedCopier?  I named it -Transformer
because, like, SDT, its behavior may change depending
on its configured components.  In any event, I think
we can, for now, forego making these mutators public
on ChainedConverter as well as you should be able to
control its source classes by controlling the source
classes of its first component, and similarly wrt dest
classes/last component.  I'll be adding the methods
for the others.

-Matt B

[SNIP]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I think for almost all transformers where source and
> destination classes 
> are not static we should make the mutators public. 
> So: 
> ChainedConverter, ConverterDecorator,
> CopierDecorator, CumulativeCopier, 
> AssemblerCopier, MultipleDestinationConverter.  I
> don't think they need 
> to be public on SimpleDelegatingTransformer.
> 
> More responses below...
> 
> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> Short answer: I think it's better to leave it
> >> protected in 
> >> BaseTransformer and just override it to be public
> in
> >> ChainedConverter.
> >>     
> >
> > Fair enough.  In my use case I was thinking
> originally
> > of the ubiquitous pattern of a TextToFoo converter
> > that uses a TextConverter to magically get all its
> > conversions and basically is a hand-run
> > ChainedConverter with two components.
> Should we make a base class for this purpose?  After
> all, entire 
> conversion frameworks have been built on Object ->
> String and String -> 
> Object conversions rather than Object -> Object
> conversions.  
> Unfortunately the name "TextConverter" is taken so
> BaseTextConverter 
> would be rather confusing :(
> 
> This is a bad name, but I'm thinking something like 
> BaseBiDirectionalTextConverter, so if I have some
> object Foo I want to 
> allow to be magically turned into all sorts of
> things then I extend 
> BaseBiDirectionalTextConverter and it automatically
> takes care of foo -> 
> (text) and (text) -> foo.
> 
> public abstract BaseBiDirectionalTextConverter
> extends BaseTransformer {
>     private Converter textConverter;
>     public abstract String toText();
>     public abstract String toObject();
> 
>     // implementation details
> }

Yep, I was thinking of this as well; just hadn't
gotten around to it yet.  :)

> 
> > Take two of
> > these and pass to a chainedconverter, so that you
> have
> > the ultimate transformation of 
> >
> > FooToTextConverter, TextToBarConverter:
> > Foo -> (text) -> Bar
> >
> > Here there are several classes that are both a
> valid
> > destination for FooToText and a valid source for
> > TextToBar.  The current ChainedConverter
> > implementation will take the first overlap it
> finds
> > and be happy.  But if it happens to choose
> Character
> > or char data will be lost if the intermediate text
> > representation is > 1 character long.
> The algorithm will go with the first match, so
> StringBuffer should be 
> chosen right?  I assume you are using this just for
> illustration 
> purposes to point out why ChainedConverter should
> have mutable source 
> and destination classes (a point I agree with).
> 

Actually I didn't go too far into how it happened, but
on a transformation I was developing I was
experiencing intermittent test failures because
occasionally Character or char was being selected. 
Another option might be to break support for these
classes out of the TextConverter... :|

> > I realized that
> > for my immediate purposes I should simply override
> the
> > setters in the TextToFoo/FooToText type classes. 
> For
> > something that might be usable out of the box, it
> > seems like it might be appropriate to open access
> to
> > these methods on ConverterDecorator and
> > CopierDecorator for a reasonable way to wrap the
> > bundled converters/copiers.  WDYT?
> >   
> I absolutely agree the mutators should be public on
> both decorators.
> 
> I hope there isn't ever a need to wrap a transformer
> bundled with Morph 
> with one of the decorators though.  After all, the
> transformers we have 
> out there already implement all the interfaces the
> decorators do and the 
> whole point of a decorator is that it implements an
> interface the 
> decorated object does not.

I guess in this case I was looking at it as kind of a
cheap proxy.

> > -Matt
> 
> Oh I don't have to write my name this time! ;)
> 
> PS - it occurred to me that we (I) need to add
> transformers that support 
> Streams.  Often the first time someone hits an
> InputStream or 
> OutputStream, they could be safely working with
> Strings or byte[] arrays 
> or something instead and get the job done.  I know
> the first time I had 
> to use an InputStream I nearly went insane because
> all I needed was a 
> freakin String.  For that matter, I guess all of the
> java.io. stuff and 
> Spring resource stuff could use transformers...
> 
> PPS - have you seen this thread
> 
>
http://www.nabble.com/-convert--Project-restart---tf2015876.html#a5603065
> 
> Now I know why Henri is interested in Morph.
> 

Actually I think that thread was the first place I
heard of Morph as well.  I've still got one of the
mails from that thread in my Morph email folder,
actually.  ;)

-Matt B

>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt S. <Mat...@wh...>]

I think for almost all transformers where source and destination classes 
are not static we should make the mutators public.  So: 
ChainedConverter, ConverterDecorator, CopierDecorator, CumulativeCopier, 
AssemblerCopier, MultipleDestinationConverter.  I don't think they need 
to be public on SimpleDelegatingTransformer.

More responses below...

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> Short answer: I think it's better to leave it
>> protected in 
>> BaseTransformer and just override it to be public in
>> ChainedConverter.
>>     
>
> Fair enough.  In my use case I was thinking originally
> of the ubiquitous pattern of a TextToFoo converter
> that uses a TextConverter to magically get all its
> conversions and basically is a hand-run
> ChainedConverter with two components.
Should we make a base class for this purpose?  After all, entire 
conversion frameworks have been built on Object -> String and String -> 
Object conversions rather than Object -> Object conversions.  
Unfortunately the name "TextConverter" is taken so BaseTextConverter 
would be rather confusing :(

This is a bad name, but I'm thinking something like 
BaseBiDirectionalTextConverter, so if I have some object Foo I want to 
allow to be magically turned into all sorts of things then I extend 
BaseBiDirectionalTextConverter and it automatically takes care of foo -> 
(text) and (text) -> foo.

public abstract BaseBiDirectionalTextConverter extends BaseTransformer {
    private Converter textConverter;
    public abstract String toText();
    public abstract String toObject();

    // implementation details
}

> Take two of
> these and pass to a chainedconverter, so that you have
> the ultimate transformation of 
>
> FooToTextConverter, TextToBarConverter:
> Foo -> (text) -> Bar
>
> Here there are several classes that are both a valid
> destination for FooToText and a valid source for
> TextToBar.  The current ChainedConverter
> implementation will take the first overlap it finds
> and be happy.  But if it happens to choose Character
> or char data will be lost if the intermediate text
> representation is > 1 character long.
The algorithm will go with the first match, so StringBuffer should be 
chosen right?  I assume you are using this just for illustration 
purposes to point out why ChainedConverter should have mutable source 
and destination classes (a point I agree with).

> I realized that
> for my immediate purposes I should simply override the
> setters in the TextToFoo/FooToText type classes.  For
> something that might be usable out of the box, it
> seems like it might be appropriate to open access to
> these methods on ConverterDecorator and
> CopierDecorator for a reasonable way to wrap the
> bundled converters/copiers.  WDYT?
>   
I absolutely agree the mutators should be public on both decorators.

I hope there isn't ever a need to wrap a transformer bundled with Morph 
with one of the decorators though.  After all, the transformers we have 
out there already implement all the interfaces the decorators do and the 
whole point of a decorator is that it implements an interface the 
decorated object does not.
> -Matt

Oh I don't have to write my name this time! ;)

PS - it occurred to me that we (I) need to add transformers that support 
Streams.  Often the first time someone hits an InputStream or 
OutputStream, they could be safely working with Strings or byte[] arrays 
or something instead and get the job done.  I know the first time I had 
to use an InputStream I nearly went insane because all I needed was a 
freakin String.  For that matter, I guess all of the java.io. stuff and 
Spring resource stuff could use transformers...

PPS - have you seen this thread

http://www.nabble.com/-convert--Project-restart---tf2015876.html#a5603065

Now I know why Henri is interested in Morph.

Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Short answer: I think it's better to leave it
> protected in 
> BaseTransformer and just override it to be public in
> ChainedConverter.

Fair enough.  In my use case I was thinking originally
of the ubiquitous pattern of a TextToFoo converter
that uses a TextConverter to magically get all its
conversions and basically is a hand-run
ChainedConverter with two components.  Take two of
these and pass to a chainedconverter, so that you have
the ultimate transformation of 

FooToTextConverter, TextToBarConverter:
Foo -> (text) -> Bar

Here there are several classes that are both a valid
destination for FooToText and a valid source for
TextToBar.  The current ChainedConverter
implementation will take the first overlap it finds
and be happy.  But if it happens to choose Character
or char data will be lost if the intermediate text
representation is > 1 character long.  I realized that
for my immediate purposes I should simply override the
setters in the TextToFoo/FooToText type classes.  For
something that might be usable out of the box, it
seems like it might be appropriate to open access to
these methods on ConverterDecorator and
CopierDecorator for a reasonable way to wrap the
bundled converters/copiers.  WDYT?

-Matt

> 
> Long answer:
> 
> I don't think it’s appropriate for all transformers
> that extend from 
> BaseTransformer to expose their source and
> destination classes as 
> mutable properties. The source and destination
> classes are the contract 
> that specifies what a transformer can do, and if an
> individual 
> transformer wants to control this, it should be free
> to do so in a 
> protected manner. An example of this would be the
> TextTransformer, which 
> has a set number of text types it can handle.
> 
> But what if a user were to want to change the
> behavior of 
> TextTransformer so that there are more or fewer
> types it could handle? 
> Well, to add a new text type to TextConverter it
> would be necessary to 
> subclass TextConverter anyway to implement the
> transformation. There is 
> a stronger case for removing capability, for example
> if you had your own 
> converter you wanted to handle char[] -> String
> conversions and so 
> wanted to limit the TextConverter’s functionality by
> reducing the source 
> and destination classes. Both of these use cases are
> somewhat artificial 
> though because there is an even simpler solution:
> just change the order 
> of the transformers in your
> SimpleDelegatingTransformer so that it gets 
> chosen before TextConverter is even tried.
> 
> There certainly are cases where transformers want
> their source and 
> destination classes to be public, and they can
> override the definition 
> in BaseTransformer. BasePropertyNameCopier does this
> so that 
> PropertyNameMatchingCopier and
> PropertyNameMappingCopier can be used for 
> simple transformations without blocking other
> transformers from being 
> used in a SimpleDelegatingTransformer.
> ChainedConverter sounds like 
> another place where it’s reasonable to make the
> source and destination 
> classes mutable.
> 
> Matt S
> 
> Matt Benson wrote:
> > I can't see a reason why we can't do this.  One
> use
> > case I am seeing is with a ChainedConverter, being
> > able to set the source and/or destination classes
> on
> > the chain components helps to direct the flow of
> the
> > chained transformation.
> >
> > WDYT?
> >
> > -Matt B
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt S. <Mat...@wh...>]

Short answer: I think it's better to leave it protected in 
BaseTransformer and just override it to be public in ChainedConverter.

Long answer:

I don't think it’s appropriate for all transformers that extend from 
BaseTransformer to expose their source and destination classes as 
mutable properties. The source and destination classes are the contract 
that specifies what a transformer can do, and if an individual 
transformer wants to control this, it should be free to do so in a 
protected manner. An example of this would be the TextTransformer, which 
has a set number of text types it can handle.

But what if a user were to want to change the behavior of 
TextTransformer so that there are more or fewer types it could handle? 
Well, to add a new text type to TextConverter it would be necessary to 
subclass TextConverter anyway to implement the transformation. There is 
a stronger case for removing capability, for example if you had your own 
converter you wanted to handle char[] -> String conversions and so 
wanted to limit the TextConverter’s functionality by reducing the source 
and destination classes. Both of these use cases are somewhat artificial 
though because there is an even simpler solution: just change the order 
of the transformers in your SimpleDelegatingTransformer so that it gets 
chosen before TextConverter is even tried.

There certainly are cases where transformers want their source and 
destination classes to be public, and they can override the definition 
in BaseTransformer. BasePropertyNameCopier does this so that 
PropertyNameMatchingCopier and PropertyNameMappingCopier can be used for 
simple transformations without blocking other transformers from being 
used in a SimpleDelegatingTransformer. ChainedConverter sounds like 
another place where it’s reasonable to make the source and destination 
classes mutable.

Matt S

Matt Benson wrote:
> I can't see a reason why we can't do this.  One use
> case I am seeing is with a ChainedConverter, being
> able to set the source and/or destination classes on
> the chain components helps to direct the flow of the
> chained transformation.
>
> WDYT?
>
> -Matt B
>   

[morph-developer] Open up access to setSource/DestinationClasses in BaseTransformer

[Matt B. <gud...@ya...>]

I can't see a reason why we can't do this.  One use
case I am seeing is with a ChainedConverter, being
able to set the source and/or destination classes on
the chain components helps to direct the flow of the
chained transformation.

WDYT?

-Matt B

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] TextConverter using null as destinationClass

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >   
> > So if TextConverter can convert null to null
> doesn't
> > that kind of step on the toes of NullConverter?
> 
> Yes, but I don't think that's a bad thing.  It makes
> the converter more 
> robust and also makes it quite reasonable to use
> standalone, outside any 
> composite containing other transformers.  If I were
> writing a method to 
> convert a String to a char[] array, I certainly
> would test for null (and 
> return null, if that was the input).  If we are to
> devote an entire 
> class to this purpose, that's all the more reason to
> include this 
> robustness IMO.

Fair enough.

> 
> > In
> > terms of an SDT with default components,
> NullConverter
> > wouldn't be needed.  On this line of inquiry, I
> have
> > now noticed that IdentityConverter is another that
> > returns source and dest classes including null,
> but
> > doesn't seem to do it properly.  Maybe we should
> > modify IdentityConverter to do the job of
> > NullConverter (convert null source to null or
> Object
> > dest) and deprecate NullConverter.  I am
> recommending
> > this in part because of the changes I made so that
> > ClassUtils includes the null type as an immutable
> > type, and the ImmutableTypesOnlyIdentityConverter
> > extends IdentityConverter.  Similarly the
> > TypeChangingGraphTransformer sets the
> immutableTypes
> > onto the IdentityConverter it finds in its list of
> > components.  Making IdentityConverter properly
> deal
> > with nulls would probably keep the source of
> > converters that use the result of
> > ClassUtils.getImmutableTypes() nice and simple.
> >   
> 
> I tried very hard to think of a good reason to keep
> NullConverter 
> around, but I am at a loss.  Deprecating it sounds
> like an excellent idea.
> 

I did the work earlier for this; I'll check it in
soon.

> >   
> >>  If something like 
> >> "hello world" is the source and the
> destinationClass
> >> is null I think we 
> >> need to throw a TransformationException.  I think
> >> this keeps the convert 
> >> implementation relatively clear while maintaining
> >> the truth that null is 
> >> an allowed destinationClass.
> >>     
> >
> > I suppose it should be exceedingly rare for a user
> to
> > actually explicitly specify that a source object
> be
> > converted to null.  It's fairly nonsensical if you
> > think about it, but you never know.
> Agreed.  Here is the only example I can think of. 
> Admittedly, the 
> implementation of this method is pretty inefficient,
> but if Morph can 
> support it I see no reason not to.
> 
> boolean isEmptyCharSequence(Object charSequence) {
>    try {
>       textConverter.convert(null, charSequence);
>       return true;
>    } catch (TransformationException e) { return
> false; }
> }
> 

Okay.  ;)

> > The existing
> > automatic null handling behavior should already
> handle
> > most cases by returning null when converting null
> to
> > any non-primitive type, including null.  I felt a
> > little weird about TextConverter being able to
> convert
> > some strings to null and not others, but I guess
> > that's no different than a text-to-number or
> similar
> > converter that may fail or succeed depending on
> the
> > validity of the source object.
> >
> >   
> >> I think convert(String.class, null) should return
> >> null rather than the 
> >> text "null".  Here's one reason (I could probably
> >> think of others if 
> >> needed): if you use the MorphFilter in your web
> >> application then you can 
> >> use expressions like <c:out 
> >>
> >>     
> >
>
value="${morph['some.expression.using.the.simple.language']}"/>.
> >   
> >>  I 
> >> would really hate to see the text "null" printed
> out
> >> by any such expression.
> >>     
> >
> > I would have hated that too; but could have seen
> it be
> > a toss-up whether null should convert to null or
> to
> > "".  In a default SDT the NullConverter would
> preempt
> > the TextConverter being able to convert null to ""
> so
> > you could provide "" behavior and have it apply
> only
> > if the TextConverter were explicitly given higher
> > precedence than the NullConverter (or
> > IdentityConverter if we go down that path).
> >   
> That's a very interesting idea.  I'm really not sure
> what to do here so 
> I will write out some advantages and disadvantages
> of both approaches.  
> What is your preference?

I really don't care; I really imagine that >=90% of
the time a user would want null to convert to a null
String... maybe we should just add a boolean property
to TextConverter saying whether null implies empty or
null.  That way Morph provides an implementation of
this rare-but-not-unheard-of conversion, the user has
to enable it explicitly, and it doesn't have to have
an entire new class to support it.  I am fairly sure
you'll be cool with this idea, so I'll go ahead and
implement this to be checked in with my next round of
changes.

br,
Matt B

> 
> Advantages:
> - Allows us to have our cake and eat it too, in that
> we aren't really 
> deciding which approach is more valid but are
> providing a (kind of) out 
> of the box solution for both conversions (null ->
> null and null -> "")
> 
> Disadvantages:
> - Putting TextConverter before IdentityConverter is
> a rather subtle way 
> to configure the behavior change that null -> null
> instead of null -> ""
> - Someone who is accustomed to the behavior of
> Morph.convert may be 
> taken by surprise when the TextConverter behaves
> differently
> 
> Of course, we could make TextConverter before
> NullConverter by default.
> 
> Advantages:
> - Less potential for NPEs in client code
> - Morph.convert will behave the same as a default
> instance of TextConverter
> 
> Disadvantages:
> - Extra cost in terms of memory and performance to
> create empty objects 
> rather than return nulls (e.g. an empty StringBuffer
> internally contains 
> a char[16] and an int when first created)
> 
> >>  Henri 
> >> has accepted some of my patches to Jakarta
> projects
> >> before and was very 
> >> friendly (which is nice, since I often get
> screamed
> >> at when I try to 
> >> contribute to open source projects).
> >>     
> >
> > That sounds like an interesting story.
> >   
> 
> Not really.  Here's a rather fascinating read if you
> want to see some 
> open source drama though:
> 
> Tomcat bug 36541: session getAttribute/setAttribute
> and removeAttribute 
> are NOT Thread safe.
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541
> 
> Matt S
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] TextConverter using null as destinationClass

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>   
> So if TextConverter can convert null to null doesn't
> that kind of step on the toes of NullConverter?

Yes, but I don't think that's a bad thing.  It makes the converter more 
robust and also makes it quite reasonable to use standalone, outside any 
composite containing other transformers.  If I were writing a method to 
convert a String to a char[] array, I certainly would test for null (and 
return null, if that was the input).  If we are to devote an entire 
class to this purpose, that's all the more reason to include this 
robustness IMO.

> In
> terms of an SDT with default components, NullConverter
> wouldn't be needed.  On this line of inquiry, I have
> now noticed that IdentityConverter is another that
> returns source and dest classes including null, but
> doesn't seem to do it properly.  Maybe we should
> modify IdentityConverter to do the job of
> NullConverter (convert null source to null or Object
> dest) and deprecate NullConverter.  I am recommending
> this in part because of the changes I made so that
> ClassUtils includes the null type as an immutable
> type, and the ImmutableTypesOnlyIdentityConverter
> extends IdentityConverter.  Similarly the
> TypeChangingGraphTransformer sets the immutableTypes
> onto the IdentityConverter it finds in its list of
> components.  Making IdentityConverter properly deal
> with nulls would probably keep the source of
> converters that use the result of
> ClassUtils.getImmutableTypes() nice and simple.
>   

I tried very hard to think of a good reason to keep NullConverter 
around, but I am at a loss.  Deprecating it sounds like an excellent idea.

>   
>>  If something like 
>> "hello world" is the source and the destinationClass
>> is null I think we 
>> need to throw a TransformationException.  I think
>> this keeps the convert 
>> implementation relatively clear while maintaining
>> the truth that null is 
>> an allowed destinationClass.
>>     
>
> I suppose it should be exceedingly rare for a user to
> actually explicitly specify that a source object be
> converted to null.  It's fairly nonsensical if you
> think about it, but you never know.
Agreed.  Here is the only example I can think of.  Admittedly, the 
implementation of this method is pretty inefficient, but if Morph can 
support it I see no reason not to.

boolean isEmptyCharSequence(Object charSequence) {
   try {
      textConverter.convert(null, charSequence);
      return true;
   } catch (TransformationException e) { return false; }
}

> The existing
> automatic null handling behavior should already handle
> most cases by returning null when converting null to
> any non-primitive type, including null.  I felt a
> little weird about TextConverter being able to convert
> some strings to null and not others, but I guess
> that's no different than a text-to-number or similar
> converter that may fail or succeed depending on the
> validity of the source object.
>
>   
>> I think convert(String.class, null) should return
>> null rather than the 
>> text "null".  Here's one reason (I could probably
>> think of others if 
>> needed): if you use the MorphFilter in your web
>> application then you can 
>> use expressions like <c:out 
>>
>>     
> value="${morph['some.expression.using.the.simple.language']}"/>.
>   
>>  I 
>> would really hate to see the text "null" printed out
>> by any such expression.
>>     
>
> I would have hated that too; but could have seen it be
> a toss-up whether null should convert to null or to
> "".  In a default SDT the NullConverter would preempt
> the TextConverter being able to convert null to "" so
> you could provide "" behavior and have it apply only
> if the TextConverter were explicitly given higher
> precedence than the NullConverter (or
> IdentityConverter if we go down that path).
>   
That's a very interesting idea.  I'm really not sure what to do here so 
I will write out some advantages and disadvantages of both approaches.  
What is your preference?

Advantages:
- Allows us to have our cake and eat it too, in that we aren't really 
deciding which approach is more valid but are providing a (kind of) out 
of the box solution for both conversions (null -> null and null -> "")

Disadvantages:
- Putting TextConverter before IdentityConverter is a rather subtle way 
to configure the behavior change that null -> null instead of null -> ""
- Someone who is accustomed to the behavior of Morph.convert may be 
taken by surprise when the TextConverter behaves differently

Of course, we could make TextConverter before NullConverter by default.

Advantages:
- Less potential for NPEs in client code
- Morph.convert will behave the same as a default instance of TextConverter

Disadvantages:
- Extra cost in terms of memory and performance to create empty objects 
rather than return nulls (e.g. an empty StringBuffer internally contains 
a char[16] and an int when first created)

>>  Henri 
>> has accepted some of my patches to Jakarta projects
>> before and was very 
>> friendly (which is nice, since I often get screamed
>> at when I try to 
>> contribute to open source projects).
>>     
>
> That sounds like an interesting story.
>   

Not really.  Here's a rather fascinating read if you want to see some 
open source drama though:

Tomcat bug 36541: session getAttribute/setAttribute and removeAttribute 
are NOT Thread safe.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541

Matt S

Re: [morph-developer] TextConverter using null as destinationClass

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I think it makes sense for TextConverter to be able
> to convert a null or 
> an empty String, char[], StringBuffer, etc. to null.

So if TextConverter can convert null to null doesn't
that kind of step on the toes of NullConverter?  In
terms of an SDT with default components, NullConverter
wouldn't be needed.  On this line of inquiry, I have
now noticed that IdentityConverter is another that
returns source and dest classes including null, but
doesn't seem to do it properly.  Maybe we should
modify IdentityConverter to do the job of
NullConverter (convert null source to null or Object
dest) and deprecate NullConverter.  I am recommending
this in part because of the changes I made so that
ClassUtils includes the null type as an immutable
type, and the ImmutableTypesOnlyIdentityConverter
extends IdentityConverter.  Similarly the
TypeChangingGraphTransformer sets the immutableTypes
onto the IdentityConverter it finds in its list of
components.  Making IdentityConverter properly deal
with nulls would probably keep the source of
converters that use the result of
ClassUtils.getImmutableTypes() nice and simple.  End
of digression.  

>  If something like 
> "hello world" is the source and the destinationClass
> is null I think we 
> need to throw a TransformationException.  I think
> this keeps the convert 
> implementation relatively clear while maintaining
> the truth that null is 
> an allowed destinationClass.

I suppose it should be exceedingly rare for a user to
actually explicitly specify that a source object be
converted to null.  It's fairly nonsensical if you
think about it, but you never know.  The existing
automatic null handling behavior should already handle
most cases by returning null when converting null to
any non-primitive type, including null.  I felt a
little weird about TextConverter being able to convert
some strings to null and not others, but I guess
that's no different than a text-to-number or similar
converter that may fail or succeed depending on the
validity of the source object.

> 
> I think convert(String.class, null) should return
> null rather than the 
> text "null".  Here's one reason (I could probably
> think of others if 
> needed): if you use the MorphFilter in your web
> application then you can 
> use expressions like <c:out 
>
value="${morph['some.expression.using.the.simple.language']}"/>.
>  I 
> would really hate to see the text "null" printed out
> by any such expression.

I would have hated that too; but could have seen it be
a toss-up whether null should convert to null or to
"".  In a default SDT the NullConverter would preempt
the TextConverter being able to convert null to "" so
you could provide "" behavior and have it apply only
if the TextConverter were explicitly given higher
precedence than the NullConverter (or
IdentityConverter if we go down that path).

> 
> I don't know if this answers your question or
> muddies the waters further 
> ;)  I think what I'm proposing is option 3 with the
> caveat that if the 
> source is not null or some type of "empty" object we
> blowup with a 
> TransformationException (similar to if you try to
> convert "Hello World" 
> to an Integer)
> 
> BTW, I saw on Jakarta General that Henri Yandall is
> still interested in 
> Morph.  It was a good call on your part to have some
> patience!

I won't lie to you; I had pretty much given up as well
until I saw Henri mention Morph in the context of
another discussion on the commons-dev list.

>  Henri 
> has accepted some of my patches to Jakarta projects
> before and was very 
> friendly (which is nice, since I often get screamed
> at when I try to 
> contribute to open source projects).

That sounds like an interesting story.

>  I'm excited at
> the prospect of us 
> moving Morph (or parts of it) to Apache :)

Yeah, I'd like to do the 1.0.2 release first but after
that--

-Matt B

> 
> Matt S
> 
> Matt Benson wrote:
> > I have noticed that TextConverter declares it is
> able
> > to use null as a source and destination class, but
> it
> > is actually not able to use null for a
> destination. 
> > And since lots of converters use a TextConverter
> to
> > provide for free multiple destination types with
> the
> > implementor only having to provide a String
> > conversion, these TextConverter consumers inherit
> the
> > problem.  This leaves a few options:
> >
> > 1. Agree that in the common paradigm converters
> allow
> > null sources but not destinations.  Because of the
> > NullConverter the majority of existing
> functionality
> > would be preserved.  The most unfortunate drawback
> of
> > this approach is that converters which declare a
> > single set of source-AND-destination types
> including
> > null (e.g. TextConverter) would have to be
> adjusted to
> > differ their listing of provided source/dest
> types.
> >
> > 2.  Alter the default isTransformableImpl behavior
> in
> > BaseTransformer (either here or in
> TransformerUtils)
> > to disallow null destinationClass.  Not sure I
> like
> > this either.
> >
> > 3.  Rework classes that declare null as a
> destination
> > type to actually be able to return null.  Most
> likely
> > here it would make sense to check for null
> > destinationType in BaseTransformer.convert()--I
> think
> > we can agree that there is only one possible
> return
> > value from a null conversion.  I would probably
> choose
> > this alternative, personally.
> >
> > In any event, we also need to determine what the
> > expected behavior is of TextConverter when
> converting
> > null to a text type.  Is it empty, or is it
> "null"? 
> > Which is more likely to serve 99% of what users
> would
> > want OOTB?
> >
> > WDYT?
> >
> > -Matt B
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] TextConverter using null as destinationClass

[Matt S. <Mat...@wh...>]

I think it makes sense for TextConverter to be able to convert a null or 
an empty String, char[], StringBuffer, etc. to null.  If something like 
"hello world" is the source and the destinationClass is null I think we 
need to throw a TransformationException.  I think this keeps the convert 
implementation relatively clear while maintaining the truth that null is 
an allowed destinationClass.

I think convert(String.class, null) should return null rather than the 
text "null".  Here's one reason (I could probably think of others if 
needed): if you use the MorphFilter in your web application then you can 
use expressions like <c:out 
value="${morph['some.expression.using.the.simple.language']}"/>.  I 
would really hate to see the text "null" printed out by any such expression.

I don't know if this answers your question or muddies the waters further 
;)  I think what I'm proposing is option 3 with the caveat that if the 
source is not null or some type of "empty" object we blowup with a 
TransformationException (similar to if you try to convert "Hello World" 
to an Integer)

BTW, I saw on Jakarta General that Henri Yandall is still interested in 
Morph.  It was a good call on your part to have some patience!  Henri 
has accepted some of my patches to Jakarta projects before and was very 
friendly (which is nice, since I often get screamed at when I try to 
contribute to open source projects).  I'm excited at the prospect of us 
moving Morph (or parts of it) to Apache :)

Matt S

Matt Benson wrote:
> I have noticed that TextConverter declares it is able
> to use null as a source and destination class, but it
> is actually not able to use null for a destination. 
> And since lots of converters use a TextConverter to
> provide for free multiple destination types with the
> implementor only having to provide a String
> conversion, these TextConverter consumers inherit the
> problem.  This leaves a few options:
>
> 1. Agree that in the common paradigm converters allow
> null sources but not destinations.  Because of the
> NullConverter the majority of existing functionality
> would be preserved.  The most unfortunate drawback of
> this approach is that converters which declare a
> single set of source-AND-destination types including
> null (e.g. TextConverter) would have to be adjusted to
> differ their listing of provided source/dest types.
>
> 2.  Alter the default isTransformableImpl behavior in
> BaseTransformer (either here or in TransformerUtils)
> to disallow null destinationClass.  Not sure I like
> this either.
>
> 3.  Rework classes that declare null as a destination
> type to actually be able to return null.  Most likely
> here it would make sense to check for null
> destinationType in BaseTransformer.convert()--I think
> we can agree that there is only one possible return
> value from a null conversion.  I would probably choose
> this alternative, personally.
>
> In any event, we also need to determine what the
> expected behavior is of TextConverter when converting
> null to a text type.  Is it empty, or is it "null"? 
> Which is more likely to serve 99% of what users would
> want OOTB?
>
> WDYT?
>
> -Matt B
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>   

[morph-developer] TextConverter using null as destinationClass

[Matt B. <gud...@ya...>]

I have noticed that TextConverter declares it is able
to use null as a source and destination class, but it
is actually not able to use null for a destination. 
And since lots of converters use a TextConverter to
provide for free multiple destination types with the
implementor only having to provide a String
conversion, these TextConverter consumers inherit the
problem.  This leaves a few options:

1. Agree that in the common paradigm converters allow
null sources but not destinations.  Because of the
NullConverter the majority of existing functionality
would be preserved.  The most unfortunate drawback of
this approach is that converters which declare a
single set of source-AND-destination types including
null (e.g. TextConverter) would have to be adjusted to
differ their listing of provided source/dest types.

2.  Alter the default isTransformableImpl behavior in
BaseTransformer (either here or in TransformerUtils)
to disallow null destinationClass.  Not sure I like
this either.

3.  Rework classes that declare null as a destination
type to actually be able to return null.  Most likely
here it would make sense to check for null
destinationType in BaseTransformer.convert()--I think
we can agree that there is only one possible return
value from a null conversion.  I would probably choose
this alternative, personally.

In any event, we also need to determine what the
expected behavior is of TextConverter when converting
null to a text type.  Is it empty, or is it "null"? 
Which is more likely to serve 99% of what users would
want OOTB?

WDYT?

-Matt B

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Spring support

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> I like net.sf.morph.integration.spring.
> 
> I can't help but think the user-facing API of Morph
> has failed to some 
> extent if you opted to implement a 
> ResourceArrayInputStreamPropertyEditor instead of a 
> ResourceArrayInputStreamConverter and tied that
> along with a 
> MorphPropertyEditor :(

Awww... I hope that comment was at least to some
extent tongue-in-cheek.  I was thinking more in terms
of general-purpose Spring extensions when I wrote
that.  I'm about to submit it to Spring JIRA in case
they want to host it (probably they won't but you
never know).  Also, since MorphPropertyEditor is in
the sandbox such a direction was less on my mind...

-Matt B

> 
> Matt S
> 
> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> What kind of Spring extensions were you thinking
> of?
> >>     
> >
> > Well, for example, I created the
> > ResourceArrayInputStream and its propertyEditor in
> > net.sf.morph.util for lack of a better place to
> put
> > it.  Actually I would like to see this stuff
> somewhere
> > more GP to Spring; maybe I should submit it as an
> > enhancement request to the Spring core and see
> where
> > it goes.  If they accept it we could deprecate and
> > extend it or some similar strategy.  :)
> >
> > Further, I was thinking of a FactoryBean that
> would
> > ease the PITA of the current strategy of including
> > default converters in SDT by putting
> > includeDefaultConverters in a FactoryBean property
> > that would then pass that info to the constructor
> in a
> > "have our cake and eat it too" type scenario.
> >
> > Another idea we might include:  a FactoryBean that
> > could create a DSLDefinedCopier from inline text
> and
> > an accompanying Spring 2 custom tag.
> >
> > [SNIP]
> >   
> >> Or if we anticipate future integrations with
> other
> >> packages than perhaps
> >> net.sf.morph.ext.spring
> >> net.sf.morph.ext.velocity
> >>
> >>     
> >
> > Not bad.
> >
> >   
> >> etc
> >>
> >> A nice convention Spring uses when integrating
> with
> >> other packages is to 
> >> put the integration in a package that describes
> the
> >> type of tool its 
> >> integrating with.  For example:
> >> org.springframework.orm.hibernate
> >>
> >>     
> >
> > I don't have a problem with this on principle...
> hmmm,
> > what about a net.sf.morph.integration.spring
> package? 
> > IMHO this kind of captures the essence of both
> > proposed package naming schemes... I'm not
> convinced
> > that the total number of Morph-provided extensions
> > would warrant "concern-based" package names.
> >
> > -Matt B
> >
> >   
> >> Matt S
> >>
> >> Matt Benson wrote:
> >>     
> >>> Thoughts on a good packagename in which we can
> >>>       
> >> place
> >>     
> >>> classes intended to support use of Morph in
> >>> conjunction with the Spring framework?
> >>>
> >>> -Matt B 
> >>>
> >>>
> __________________________________________________
> >>> Do You Yahoo!?
> >>> Tired of spam?  Yahoo! Mail has the best spam
> >>>       
> >> protection around 
> >>     
> >>> http://mail.yahoo.com 
> >>>
> >>>
> >>>       
> >
>
-------------------------------------------------------------------------
> >   
> >>> This SF.net email is sponsored by DB2 Express
> >>> Download DB2 Express C - the FREE version of DB2
> >>>       
> >> express and take
> >>     
> >>> control of your XML. No limits. Just data. Click
> >>>       
> >> to get it now.
> >>     
> >>> http://sourceforge.net/powerbar/db2/
> >>> _______________________________________________
> >>> morph-developer mailing list
> >>> mor...@li...
> >>>
> >>>       
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >   
> >>>   
> >>>       
> >>
> >>     
> >
>
-------------------------------------------------------------------------
> >   
> >> This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2
> >> express and take
> >> control of your XML. No limits. Just data. Click
> to
> >> get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> morph-developer mailing list
> >> mor...@li...
> >>
> >>     
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >   
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Spring support

[Matt S. <Mat...@wh...>]

I like net.sf.morph.integration.spring.

I can't help but think the user-facing API of Morph has failed to some 
extent if you opted to implement a 
ResourceArrayInputStreamPropertyEditor instead of a 
ResourceArrayInputStreamConverter and tied that along with a 
MorphPropertyEditor :(

Matt S

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> What kind of Spring extensions were you thinking of?
>>     
>
> Well, for example, I created the
> ResourceArrayInputStream and its propertyEditor in
> net.sf.morph.util for lack of a better place to put
> it.  Actually I would like to see this stuff somewhere
> more GP to Spring; maybe I should submit it as an
> enhancement request to the Spring core and see where
> it goes.  If they accept it we could deprecate and
> extend it or some similar strategy.  :)
>
> Further, I was thinking of a FactoryBean that would
> ease the PITA of the current strategy of including
> default converters in SDT by putting
> includeDefaultConverters in a FactoryBean property
> that would then pass that info to the constructor in a
> "have our cake and eat it too" type scenario.
>
> Another idea we might include:  a FactoryBean that
> could create a DSLDefinedCopier from inline text and
> an accompanying Spring 2 custom tag.
>
> [SNIP]
>   
>> Or if we anticipate future integrations with other
>> packages than perhaps
>> net.sf.morph.ext.spring
>> net.sf.morph.ext.velocity
>>
>>     
>
> Not bad.
>
>   
>> etc
>>
>> A nice convention Spring uses when integrating with
>> other packages is to 
>> put the integration in a package that describes the
>> type of tool its 
>> integrating with.  For example:
>> org.springframework.orm.hibernate
>>
>>     
>
> I don't have a problem with this on principle... hmmm,
> what about a net.sf.morph.integration.spring package? 
> IMHO this kind of captures the essence of both
> proposed package naming schemes... I'm not convinced
> that the total number of Morph-provided extensions
> would warrant "concern-based" package names.
>
> -Matt B
>
>   
>> Matt S
>>
>> Matt Benson wrote:
>>     
>>> Thoughts on a good packagename in which we can
>>>       
>> place
>>     
>>> classes intended to support use of Morph in
>>> conjunction with the Spring framework?
>>>
>>> -Matt B 
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam
>>>       
>> protection around 
>>     
>>> http://mail.yahoo.com 
>>>
>>>
>>>       
> -------------------------------------------------------------------------
>   
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2
>>>       
>> express and take
>>     
>>> control of your XML. No limits. Just data. Click
>>>       
>> to get it now.
>>     
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> morph-developer mailing list
>>> mor...@li...
>>>
>>>       
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>   
>>>   
>>>       
>>
>>     
> -------------------------------------------------------------------------
>   
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2
>> express and take
>> control of your XML. No limits. Just data. Click to
>> get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> morph-developer mailing list
>> mor...@li...
>>
>>     
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>   
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>   

Re: [morph-developer] Spring support

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> What kind of Spring extensions were you thinking of?

Well, for example, I created the
ResourceArrayInputStream and its propertyEditor in
net.sf.morph.util for lack of a better place to put
it.  Actually I would like to see this stuff somewhere
more GP to Spring; maybe I should submit it as an
enhancement request to the Spring core and see where
it goes.  If they accept it we could deprecate and
extend it or some similar strategy.  :)

Further, I was thinking of a FactoryBean that would
ease the PITA of the current strategy of including
default converters in SDT by putting
includeDefaultConverters in a FactoryBean property
that would then pass that info to the constructor in a
"have our cake and eat it too" type scenario.

Another idea we might include:  a FactoryBean that
could create a DSLDefinedCopier from inline text and
an accompanying Spring 2 custom tag.

[SNIP]
> Or if we anticipate future integrations with other
> packages than perhaps
> net.sf.morph.ext.spring
> net.sf.morph.ext.velocity
> 

Not bad.

> etc
> 
> A nice convention Spring uses when integrating with
> other packages is to 
> put the integration in a package that describes the
> type of tool its 
> integrating with.  For example:
> org.springframework.orm.hibernate
> 

I don't have a problem with this on principle... hmmm,
what about a net.sf.morph.integration.spring package? 
IMHO this kind of captures the essence of both
proposed package naming schemes... I'm not convinced
that the total number of Morph-provided extensions
would warrant "concern-based" package names.

-Matt B

> Matt S
> 
> Matt Benson wrote:
> > Thoughts on a good packagename in which we can
> place
> > classes intended to support use of Morph in
> > conjunction with the Spring framework?
> >
> > -Matt B 
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] Spring support

[Matt S. <Mat...@wh...>]

What kind of Spring extensions were you thinking of?  So far there are 
integrations with Spring in various places:
sandbox: net.sf.morph.beans.MorphBeanWrapper (not really implemented or 
used)
sandbox: net.sf.morph.beans.MorphPropertyEditor (ready for prime time, 
probably)
sandbox: net.sf.morph.beans.ConverterDelegatingPropertyEditor (looks 
like a duplicate of MorphPropertyEditor)

sandbox: net.sf.morph.beans.PropertyEditorManagerConverter - this is a 
converter that delegates to java.beans.PropertyEditorManager, so I guess 
this isn't really directly Spring related

core: BaseTransformer.getLocale() - retrieves Locale from Spring-created 
ThreadLocal, if available

If you're thinking of a rather tight integration with one or more 
features, perhaps we should do a new package like
net.sf.morph.spring

Or if we anticipate future integrations with other packages than perhaps
net.sf.morph.ext.spring
net.sf.morph.ext.velocity

etc

A nice convention Spring uses when integrating with other packages is to 
put the integration in a package that describes the type of tool its 
integrating with.  For example:
org.springframework.orm.hibernate

Matt S

Matt Benson wrote:
> Thoughts on a good packagename in which we can place
> classes intended to support use of Morph in
> conjunction with the Spring framework?
>
> -Matt B 
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>   

[morph-developer] Spring support

[Matt B. <gud...@ya...>]

Thoughts on a good packagename in which we can place
classes intended to support use of Morph in
conjunction with the Spring framework?

-Matt B 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] null as copy source

[Matt B. <gud...@ya...>]

Matt,
  Your proposal sounds fine to me, as long as we
realize we will have to fix some test cases that
expect a copy with a null source to fail.  :)

-Matt B

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> > A simplified use case:
> >
> > I have an object hierarchy of which certain
> classes
> > represent collections (but are not "Collection"s).
>  I
> > may build an object graph that needs to have
> another
> > graph copied to it.  Parts of the source graph may
> be
> > null, but for my purposes I need a copier that
> knows
> > how to copy null on the source graph to the
> collection
> > type on the destination graph by making it empty. 
> It
> > was a one-line change to BaseTransformer.copy() to
> > allow me to do this.  If you are not "married to"
> the
> > idea that null is NEVER a valid copy source, can
> we
> > let this change stand?  As far as I can see this
> is
> > the only way to completely correctly satisfy this
> > particular use case, so this indicates to me that
> > occasionally there may be a reason to allow this.
> >   
> That is exactly the use case I had not thought of. 
> The change sounds 
> perfectly valid to me :)
> 
> Given the use case you mention, I actually think we
> should take this 
> even further and remove the exception altogether. 
> If null can be a 
> valid source object (which your use case
> demonstrates that it is), then 
> there's no reason to throw an exception.  This would
> almost be like 
> throwing an exception if an empty collection or bean
> with no properties 
> was found, it just doesn't make a whole lot of
> sense.  So I propose this:
> 
>         if (source == null &&
> isAutomaticallyHandlingNulls()) {
>             return; // nothing to copy, so we're
> done
>         }
> 
> Matt S
> 
> > -Matt B
> >
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> The idea behind a convert operation is you are
> >> transforming one object 
> >> into another object.  I think it can make sense
> to
> >> transform null to 
> >> "null" (a String containing 4 characters) or
> >> something else, so a source 
> >> of null on a convert operation makes sense.
> >>
> >> The idea behind a copy operation is you are
> taking
> >> information from one 
> >> object and copying that information to some other
> >> object.  A null by 
> >> definition is nothing, so to me it doesn't make
> >> sense that you're 
> >> copying nothing onto something.  I can't actually
> >> write down nothing, 
> >> it's the same as having not written anything at
> all.
> >>
> >> I'm not married to the idea that null sources are
> >> allowed for 
> >> conversions but not for copy operations, but I
> can't
> >> think of an example 
> >> where copying a null onto some other object would
> >> actually make sense.  
> >> I would expect this to be a programmer error, and
> so
> >> that is why a 
> >> TransformationException is thrown.
> >>
> >> Matt S
> >>
> >> Matt Benson wrote:
> >>     
> >>> Currently the Copier interface carries the
> >>>       
> >> implicit
> >>     
> >>> message that the source object cannot be null. 
> >>>       
> >> Should
> >>     
> >>> we persist in this assumption, or do we believe
> >>>       
> >> it's
> >>     
> >>> possible sometimes that null can be a legitimate
> >>>       
> >> copy
> >>     
> >>> source?
> >>>
> >>> -Matt B
> >>>
> >>>
> __________________________________________________
> >>> Do You Yahoo!?
> >>> Tired of spam?  Yahoo! Mail has the best spam
> >>>       
> >> protection around 
> >>     
> >>> http://mail.yahoo.com 
> >>>
> >>>
> >>>       
> >
>
-------------------------------------------------------------------------
> >   
> >>> This SF.net email is sponsored by DB2 Express
> >>> Download DB2 Express C - the FREE version of DB2
> >>>       
> >> express and take
> >>     
> >>> control of your XML. No limits. Just data. Click
> >>>       
> >> to get it now.
> >>     
> >>> http://sourceforge.net/powerbar/db2/
> >>> _______________________________________________
> >>> morph-developer mailing list
> >>> mor...@li...
> >>>
> >>>       
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >   
> >>>   
> >>>       
> >>
> >>     
> >
>
-------------------------------------------------------------------------
> >   
> >> This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2
> >> express and take
> >> control of your XML. No limits. Just data. Click
> to
> >> get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> morph-developer mailing list
> >> mor...@li...
> >>
> >>     
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >   
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [morph-developer] null as copy source

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> A simplified use case:
>
> I have an object hierarchy of which certain classes
> represent collections (but are not "Collection"s).  I
> may build an object graph that needs to have another
> graph copied to it.  Parts of the source graph may be
> null, but for my purposes I need a copier that knows
> how to copy null on the source graph to the collection
> type on the destination graph by making it empty.  It
> was a one-line change to BaseTransformer.copy() to
> allow me to do this.  If you are not "married to" the
> idea that null is NEVER a valid copy source, can we
> let this change stand?  As far as I can see this is
> the only way to completely correctly satisfy this
> particular use case, so this indicates to me that
> occasionally there may be a reason to allow this.
>   
That is exactly the use case I had not thought of.  The change sounds 
perfectly valid to me :)

Given the use case you mention, I actually think we should take this 
even further and remove the exception altogether.  If null can be a 
valid source object (which your use case demonstrates that it is), then 
there's no reason to throw an exception.  This would almost be like 
throwing an exception if an empty collection or bean with no properties 
was found, it just doesn't make a whole lot of sense.  So I propose this:

        if (source == null && isAutomaticallyHandlingNulls()) {
            return; // nothing to copy, so we're done
        }

Matt S

> -Matt B
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> The idea behind a convert operation is you are
>> transforming one object 
>> into another object.  I think it can make sense to
>> transform null to 
>> "null" (a String containing 4 characters) or
>> something else, so a source 
>> of null on a convert operation makes sense.
>>
>> The idea behind a copy operation is you are taking
>> information from one 
>> object and copying that information to some other
>> object.  A null by 
>> definition is nothing, so to me it doesn't make
>> sense that you're 
>> copying nothing onto something.  I can't actually
>> write down nothing, 
>> it's the same as having not written anything at all.
>>
>> I'm not married to the idea that null sources are
>> allowed for 
>> conversions but not for copy operations, but I can't
>> think of an example 
>> where copying a null onto some other object would
>> actually make sense.  
>> I would expect this to be a programmer error, and so
>> that is why a 
>> TransformationException is thrown.
>>
>> Matt S
>>
>> Matt Benson wrote:
>>     
>>> Currently the Copier interface carries the
>>>       
>> implicit
>>     
>>> message that the source object cannot be null. 
>>>       
>> Should
>>     
>>> we persist in this assumption, or do we believe
>>>       
>> it's
>>     
>>> possible sometimes that null can be a legitimate
>>>       
>> copy
>>     
>>> source?
>>>
>>> -Matt B
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam
>>>       
>> protection around 
>>     
>>> http://mail.yahoo.com 
>>>
>>>
>>>       
> -------------------------------------------------------------------------
>   
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2
>>>       
>> express and take
>>     
>>> control of your XML. No limits. Just data. Click
>>>       
>> to get it now.
>>     
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> morph-developer mailing list
>>> mor...@li...
>>>
>>>       
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>   
>>>   
>>>       
>>
>>     
> -------------------------------------------------------------------------
>   
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2
>> express and take
>> control of your XML. No limits. Just data. Click to
>> get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> morph-developer mailing list
>> mor...@li...
>>
>>     
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>   
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>   

Re: [morph-developer] null as copy source

[Matt B. <gud...@ya...>]

A simplified use case:

I have an object hierarchy of which certain classes
represent collections (but are not "Collection"s).  I
may build an object graph that needs to have another
graph copied to it.  Parts of the source graph may be
null, but for my purposes I need a copier that knows
how to copy null on the source graph to the collection
type on the destination graph by making it empty.  It
was a one-line change to BaseTransformer.copy() to
allow me to do this.  If you are not "married to" the
idea that null is NEVER a valid copy source, can we
let this change stand?  As far as I can see this is
the only way to completely correctly satisfy this
particular use case, so this indicates to me that
occasionally there may be a reason to allow this.

-Matt B

--- Matt Sgarlata
<Mat...@wh...> wrote:

> The idea behind a convert operation is you are
> transforming one object 
> into another object.  I think it can make sense to
> transform null to 
> "null" (a String containing 4 characters) or
> something else, so a source 
> of null on a convert operation makes sense.
> 
> The idea behind a copy operation is you are taking
> information from one 
> object and copying that information to some other
> object.  A null by 
> definition is nothing, so to me it doesn't make
> sense that you're 
> copying nothing onto something.  I can't actually
> write down nothing, 
> it's the same as having not written anything at all.
> 
> I'm not married to the idea that null sources are
> allowed for 
> conversions but not for copy operations, but I can't
> think of an example 
> where copying a null onto some other object would
> actually make sense.  
> I would expect this to be a programmer error, and so
> that is why a 
> TransformationException is thrown.
> 
> Matt S
> 
> Matt Benson wrote:
> > Currently the Copier interface carries the
> implicit
> > message that the source object cannot be null. 
> Should
> > we persist in this assumption, or do we believe
> it's
> > possible sometimes that null can be a legitimate
> copy
> > source?
> >
> > -Matt B
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com