google-code-export / protostuff

Automatically exported from code.google.com/p/protostuff
Apache License 2.0
1 stars 1 forks source link

Add support for transparent handling of non-standard collections #88

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
At the moment, only standard java collections are handled.  Exception is thrown 
otherwise.

Original issue reported on code.google.com by david.yu...@gmail.com on 21 Oct 2011 at 5:51

GoogleCodeExporter commented 9 years ago
Hi,

I was thinking if an approach similar to JAXB's @XmlAdapter approach could be 
used?
http://blog.bdoughan.com/2010/07/xmladapter-jaxbs-secret-weapon.html

The idea is to map custom unmappable collections to something mappable, when 
doing serialization. When deserializing, the opposite conversion is done. 

What do you think?

-Leo

Original comment by romixlev on 26 Mar 2012 at 6:53

GoogleCodeExporter commented 9 years ago
Looking at the MyMapAdapter example, I see a lot of overhead transferring the 
map's entryset to another object.

Annotation binding is something that will require a new module (on top of 
runtime).

Original comment by david.yu...@gmail.com on 27 Mar 2012 at 1:57

GoogleCodeExporter commented 9 years ago
> Looking at the MyMapAdapter example, I see a lot of overhead transferring the 
> map's entryset to another object.

I agree that it has quite some overhead. But on the other hand, if we think 
about a free-form custom collection (e.g. not even derived from Map, Set of 
List interfaces), _any_ kind of a generic serialization mechanism would 
probably require its exposure as a set of entries. And then upon serialization 
this set of entries can be converted back to the internal representation used 
by this custom collection. Or do you see a more efficient and generic way to 
achieve the same?

> Annotation binding is something that will require a new module (on top of 
runtime).

Annotation usage is no mandatory. There are other ways to achieve similar 
result. Some sort of registration, like we do for classes with IdStrategy could 
be used.

Original comment by romixlev on 27 Mar 2012 at 1:35

GoogleCodeExporter commented 9 years ago
This is covered by my latest patch on issue 96.  Custom maps and collections 
are supported on any IdStrategy.

I guess that covers your use case?

Original comment by david.yu...@gmail.com on 27 Mar 2012 at 1:39

GoogleCodeExporter commented 9 years ago
> This is covered by my latest patch on issue 96.  Custom maps and collections 
are 
> supported on any IdStrategy.
> I guess that covers your use case?

Oops. I first read and commented on this issue, before I noticed your comments 
on issue 96. 

I think your patch covers most of my use-cases. 
But I'm still wondering about very custom collections (i.e. they are 
semantically collections, but are not derived from any standard collection 
interfaces). See my comment on issue 96 please.

Original comment by romixlev on 27 Mar 2012 at 2:37

GoogleCodeExporter commented 9 years ago
@rev 1453

Original comment by david.yu...@gmail.com on 29 Mar 2012 at 5:09