Support for Thrift types
Closed this issue · 11 comments
This is a feature request:
I'd like to be able to parse yaml into a Thrift object. Thrift generated
classes differ slightly from JavaBean semantics, so java.beans.Introspector
fails to find getter, setter methods. Instead, FieldProperty instances end up
being used to access and update Thrift type public fields. Unfortunately, if
you set a Thrift object's field directly without using its associated setter,
internal "isSet" state for that field isn't updated, so things break.
I've created a simple subclass of PropertyUtils and Properties
(ThriftPropertyUtils, ThriftProperty) which make use of
com.twitter.elephantbird.thrift.TStructDescriptor (from Twitter Elephant Bird
Core) and Thrift APIs to resolve the above issue, but perhaps there's a cleaner
mechanism by which this can be achieved.
If there's interest, I'd be happy to contribute this code.
Original issue reported on code.google.com by andrew.s...@gmail.com
on 14 Nov 2012 at 8:55
Feel free to contribute the code.
Original comment by py4fun@gmail.com
on 14 Nov 2012 at 3:22
- Changed state: Accepted
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
Does Google Code support github-esque pull requests? I'm new to hg, so for now
I'll just post a patch file.
Original comment by andrew.s...@gmail.com
on 14 Nov 2012 at 6:58
See attached for patch which adds "snakeyaml-thrift" extension module
containing subclasses and unit tests.
Original comment by andrew.s...@gmail.com
on 14 Nov 2012 at 7:01
Attachments:
Google code does not have the 'pull request' but you can clone a repository
(http://code.google.com/p/snakeyaml/source/clones) and we can pull your changes
when we get the green light.
This is a major change. At the moment SnakeYAML does not have any dependency at
all. This proposal introduces not only Java dependencies but also Thrift must
be installed in order to run the tests.
If you need to make a change in the core SnakeYAML to support Thrift then let
us see what we can do.
Original comment by py4fun@gmail.com
on 16 Nov 2012 at 8:35
The new code introduces no new dependencies to the core SnakeYAML module.
Instead, it adds a new module which isolates the new dependencies. A maven
build within the root (core) module should be completely unaffected by the new
module. Users interested in building the thrift module would need the thrift
binary installed.
Original comment by andrew.s...@gmail.com
on 16 Nov 2012 at 8:39
Should we create a separate independent project for this code ? What are the
advantages to have the two projects together ?
Original comment by py4fun@gmail.com
on 16 Nov 2012 at 7:41
I feel like it might be best to keep direct extensions to snakeyaml close to
home, bundled within the same source repo. Here are some motivations:
* Easy for users to find extensions if they're all hosted in one place.
* Extensions which are hosted here are more likely to be trusted by end users.
* Code reviews are likely to be of higher quality given snakeyaml authors are
involved.
* Easy for contributors to pattern new extensions after existing ones.
* It's become somewhat standard practice to bundle extensions in this way. See
for instance Apache Hadoop and Pig.
Original comment by andrew.s...@gmail.com
on 22 Nov 2012 at 10:42
Another for the list: As snakeyaml is improved / refactored, extensions are
more likely to be kept up-to-date by community if they're included here.
Original comment by andrew.s...@gmail.com
on 22 Nov 2012 at 10:44
1) I think most of the above is perfectly valid even if the source is hosted as
a separate repository
2) if this extension is inside SnakeYAML, it implies the SnakeYAML team is
responsible for maintenance. At the moment we cannot even build it because of
too heavy external dependencies. Do you expect the SnakeYAML team to support
this extension ?
3) Apache Hadoop and Pid is a good example. Pig resides in a separate
repository, and they may have an independent release cycle
http://svn.apache.org/viewvc/pig/trunk/
Original comment by py4fun@gmail.com
on 23 Nov 2012 at 8:45
> 1) I think most of the above is perfectly valid even if the source is hosted
as a separate repository
I don't see how most of my arguments could be construed to support hosting the
thrift extension in a separate repo.
> 2) if this extension is inside SnakeYAML, it implies the SnakeYAML team is
responsible for maintenance. At the moment we cannot even build it because of
too heavy external dependencies. Do you expect the SnakeYAML team to support
this extension ?
Any contribution which is accepted by an OSS project I'd expect to be
supported. If the burden of support is too great, I'd suggest looking for more
maintainers / committers, or simply rejecting the contrib.
> 3) Apache Hadoop and Pid is a good example. Pig resides in a separate
repository, and they may have an independent release cycle
http://svn.apache.org/viewvc/pig/trunk/
To clarify, both Hadoop and Pig include contrib paths within their repos which
include separate projects and extensions for those projects, respectively. The
contribs are maintained along with the parent project:
http://svn.apache.org/viewvc/pig/trunk/contrib/
http://svn.apache.org/viewvc/hadoop/common/tags/release-0.20.2/src/contrib/
Please feel free to close this issue.
Original comment by andrew.s...@gmail.com
on 23 Nov 2012 at 5:26
Original comment by py4fun@gmail.com
on 3 Jan 2013 at 2:52
- Changed state: WontFix