Re: stand alone avro-tools prints log4j warning

[durp]

So there are a couple of ways to skin this cat. I did this in zsh.

​1) Create a wrapper < I called mine "logdiscarder"

#!/bin/zsh
log4jArgs() {
  log4jPropsFile="/tmp/avro-tools.log4j.properties"
  if [[ ! -a "$log4jPropsFile" ]]; then
tmpProps=$(mktemp $log4jPropsFile)
echo "log4j.rootLogger=INFO, devnull" >> $tmpProps
echo "log4j.appender.devnull=org.apache.log4j.varia.NullAppender" >>
$tmpProps
  fi
  log4jprops="-Dlog4j.configuration=file:$log4jPropsFile"
}
MYSELF=`which "$0" 2>/dev/null`
[ $? -gt 0 -a -f "$0" ] && MYSELF="./$0"
log4jArgs
java_args+=$log4jprops
java=java
if [[ -a "$JAVA_HOME" ]]; then
  java="$JAVA_HOME/bin/java"
fi
exec "$java" $java_args -jar $MYSELF "$@"
exit 1

2) Wrap it around the jar:

cat nullifier avro-tools-1.8.1.jar > avro-tools && chmod 777 avro-tools

3) Put in your path and then enjoy a log noise and java -jar free avro
tools:

avro-tools getschema  



--
View this message in context: 
http://apache-avro.679487.n3.nabble.com/stand-alone-avro-tools-prints-log4j-warning-tp4035985p4036343.html
Sent from the Avro - Developers mailing list archive at Nabble.com.

[jira] [Commented] (AVRO-1957) TimeConversions do not implement getRecommendedSchema()

[Ryan Blue (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709886#comment-15709886
 ] 

Ryan Blue commented on AVRO-1957:
-

I'll review this for inclusion. Thanks for following up.

> TimeConversions do not implement getRecommendedSchema()
> ---
>
> Key: AVRO-1957
> URL: https://issues.apache.org/jira/browse/AVRO-1957
> Project: Avro
>  Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Sean Timm
>
> org.apache.avro.data.TimeConversions.TimestampConversion and other date and 
> time conversions do not implement getRecommendedSchema(). When trying to 
> dynamically generate an Avro schema from a pojo that contains a DateTime 
> object using ReflectData, I get an unsupported operation exception.
> I think the implementation should be as simple as
> {code}
> @Override
> public Schema getRecommendedSchema() {
>   return 
> LogicalTypes.timestampMillis().addToSchema(Schema.create(Schema.Type.LONG));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1957) TimeConversions do not implement getRecommendedSchema()

[Sean Timm (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709801#comment-15709801
 ] 

Sean Timm commented on AVRO-1957:
-

If possible, it would be nice to get this in to 1.8.2. It is a fairly simple 
fix with PR and unit test.

> TimeConversions do not implement getRecommendedSchema()
> ---
>
> Key: AVRO-1957
> URL: https://issues.apache.org/jira/browse/AVRO-1957
> Project: Avro
>  Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Sean Timm
>
> org.apache.avro.data.TimeConversions.TimestampConversion and other date and 
> time conversions do not implement getRecommendedSchema(). When trying to 
> dynamically generate an Avro schema from a pojo that contains a DateTime 
> object using ReflectData, I get an unsupported operation exception.
> I think the implementation should be as simple as
> {code}
> @Override
> public Schema getRecommendedSchema() {
>   return 
> LogicalTypes.timestampMillis().addToSchema(Schema.create(Schema.Type.LONG));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1966) NPE When copying builder with nullable record

[Niels Basjes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niels Basjes updated AVRO-1966:
---
Status: Patch Available  (was: Open)

> NPE When copying builder with nullable record
> -
>
> Key: AVRO-1966
> URL: https://issues.apache.org/jira/browse/AVRO-1966
> Project: Avro
>  Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Critical
> Fix For: 1.8.2
>
>
> Assume a schema with a record that embeds a record that is optional (i.e. the 
> reference is union with null) and has the default value null.
> Then create a builder and copy that builder into a new builder.
> Using this copy will yield a NulPointerException. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Avro 1.8.2 release

[Niels Basjes]

This jira and pull request for this NPE:

https://issues.apache.org/jira/browse/AVRO-1966
https://github.com/apache/avro/pull/166

On Wed, Nov 30, 2016 at 9:59 PM, Niels Basjes  wrote:

> Hi Guys,
>
> Today a colleague of mine ran into a nasty NPE in the generated code.
> I found and fixed it.
> Can you please review it.
> I would really like to see this one go into the 1.8.2 is it is possible.
>
> Thanks
>
> Niels Basjes
>
> On Mon, Oct 31, 2016 at 6:22 PM, S G  wrote:
>
>> Thanks for merging the patch Ryan. Appreciate it !
>>
>> On Sun, Oct 30, 2016 at 1:59 PM, Ryan Blue 
>> wrote:
>>
>> > SG,
>> >
>> > I'll take a look at it. Thanks!
>> >
>> > rb
>> >
>> > On Sun, Oct 30, 2016 at 1:58 PM, S G  wrote:
>> >
>> > > Hey Ryan,
>> > >
>> > > Any chance https://github.com/apache/avro/pull/113 can make it to
>> this
>> > > release?
>> > > Its been pending review for a couple months now.
>> > >
>> > > Thanks
>> > > SG
>> > >
>> > > On Sun, Oct 30, 2016 at 1:46 PM, Ryan Blue  wrote:
>> > >
>> > > > Hi everyone,
>> > > >
>> > > > I'm going to try to get a 1.8.2 release candidate out this week.
>> > There's
>> > > > only one issue that I think is a blocker on AVRO-1885, and I think
>> we
>> > can
>> > > > get that bug fixed. If anyone would like to get other commits in or
>> > think
>> > > > there are more blockers, please link them to AVRO-1885 and we can
>> > discuss
>> > > > on that issue.
>> > > >
>> > > > Thanks!
>> > > >
>> > > > rb
>> > > >
>> > > > --
>> > > > Ryan Blue
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Ryan Blue
>> > Software Engineer
>> > Netflix
>> >
>>
>
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>



-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

Re: Avro 1.8.2 release

[Niels Basjes]

Hi Guys,

Today a colleague of mine ran into a nasty NPE in the generated code.
I found and fixed it.
Can you please review it.
I would really like to see this one go into the 1.8.2 is it is possible.

Thanks

Niels Basjes

On Mon, Oct 31, 2016 at 6:22 PM, S G  wrote:

> Thanks for merging the patch Ryan. Appreciate it !
>
> On Sun, Oct 30, 2016 at 1:59 PM, Ryan Blue 
> wrote:
>
> > SG,
> >
> > I'll take a look at it. Thanks!
> >
> > rb
> >
> > On Sun, Oct 30, 2016 at 1:58 PM, S G  wrote:
> >
> > > Hey Ryan,
> > >
> > > Any chance https://github.com/apache/avro/pull/113 can make it to this
> > > release?
> > > Its been pending review for a couple months now.
> > >
> > > Thanks
> > > SG
> > >
> > > On Sun, Oct 30, 2016 at 1:46 PM, Ryan Blue  wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I'm going to try to get a 1.8.2 release candidate out this week.
> > There's
> > > > only one issue that I think is a blocker on AVRO-1885, and I think we
> > can
> > > > get that bug fixed. If anyone would like to get other commits in or
> > think
> > > > there are more blockers, please link them to AVRO-1885 and we can
> > discuss
> > > > on that issue.
> > > >
> > > > Thanks!
> > > >
> > > > rb
> > > >
> > > > --
> > > > Ryan Blue
> > > >
> > >
> >
> >
> >
> > --
> > Ryan Blue
> > Software Engineer
> > Netflix
> >
>



-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

[jira] [Commented] (AVRO-1966) NPE When copying builder with nullable record

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709751#comment-15709751
 ] 

ASF GitHub Bot commented on AVRO-1966:
--

GitHub user nielsbasjes opened a pull request:

https://github.com/apache/avro/pull/166

AVRO-1966: Java: Fix NPE When copying builder with nullable record.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nielsbasjes/avro AVRO-1966

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/166.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #166


commit a53a4fd10072471aa7c8170499a10792e61e0d95
Author: Niels Basjes 
Date:   2016-11-30T20:50:13Z

AVRO-1966: Java: Fix NPE When copying builder with nullable record.




> NPE When copying builder with nullable record
> -
>
> Key: AVRO-1966
> URL: https://issues.apache.org/jira/browse/AVRO-1966
> Project: Avro
>  Issue Type: Bug
>Affects Versions: 1.8.1
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Critical
> Fix For: 1.8.2
>
>
> Assume a schema with a record that embeds a record that is optional (i.e. the 
> reference is union with null) and has the default value null.
> Then create a builder and copy that builder into a new builder.
> Using this copy will yield a NulPointerException. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] avro pull request #166: AVRO-1966: Java: Fix NPE When copying builder with n...

[nielsbasjes]

GitHub user nielsbasjes opened a pull request:

https://github.com/apache/avro/pull/166

AVRO-1966: Java: Fix NPE When copying builder with nullable record.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nielsbasjes/avro AVRO-1966

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/166.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #166


commit a53a4fd10072471aa7c8170499a10792e61e0d95
Author: Niels Basjes 
Date:   2016-11-30T20:50:13Z

AVRO-1966: Java: Fix NPE When copying builder with nullable record.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (AVRO-1966) NPE When copying builder with nullable record

[Niels Basjes (JIRA)]

Niels Basjes created AVRO-1966:
--

 Summary: NPE When copying builder with nullable record
 Key: AVRO-1966
 URL: https://issues.apache.org/jira/browse/AVRO-1966
 Project: Avro
  Issue Type: Bug
Affects Versions: 1.8.1
Reporter: Niels Basjes
Assignee: Niels Basjes
Priority: Critical
 Fix For: 1.8.2


Assume a schema with a record that embeds a record that is optional (i.e. the 
reference is union with null) and has the default value null.

Then create a builder and copy that builder into a new builder.
Using this copy will yield a NulPointerException. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1965) Reparsing an existing schema mutates the schema

[Doug Cutting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Doug Cutting updated AVRO-1965:
---
Attachment: AVRO-1965.patch

Here's a patch that should fix this.  The null namespace was not set correctly 
for nested schemas when parsing.

> Reparsing an existing schema mutates the schema
> ---
>
> Key: AVRO-1965
> URL: https://issues.apache.org/jira/browse/AVRO-1965
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: David Maughan
>Priority: Minor
> Fix For: 1.8.2
>
> Attachments: AVRO-1965.patch
>
>
> h2. Overview
> In certain scenarios re-parsing a schema constructed via {{SchemaBuilder}} or 
> {{Schema.createRecord}} produces a schema that is no longer equal to the 
> original. In the below example, after parsing the existing schema, the 
> namespace of the top level record is cascaded down to the bottom level 
> record. Note that the way the top level record is being created with the 
> namespace as part of the name {{default.a}} is the same way Hive's 
> {{AvroSerDe}} constructs a schema from a Hive table's metadata.
> h2. Failing test case
> {code}
> Schema d = SchemaBuilder.builder().intType();
> Schema c = 
> SchemaBuilder.record("c").fields().name("d").type(d).noDefault().endRecord();
> Schema b = 
> SchemaBuilder.record("b").fields().name("c").type(c).noDefault().endRecord();
> Schema a1 = 
> SchemaBuilder.record("default.a").fields().name("b").type(b).noDefault().endRecord();
> Schema a2 = new Schema.Parser().parse(a1.toString());
> // a1 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","fields":[{"name":"d","type":"int"}]}}]}}]}
> // a2 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","namespace":"default","fields":[{"name":"d","type":"int"}]}}]}}]}
> assertThat(a2, is(a1));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1965) Reparsing an existing schema mutates the schema

[Doug Cutting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Doug Cutting updated AVRO-1965:
---
Priority: Major  (was: Minor)

> Reparsing an existing schema mutates the schema
> ---
>
> Key: AVRO-1965
> URL: https://issues.apache.org/jira/browse/AVRO-1965
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: David Maughan
>Assignee: Doug Cutting
> Fix For: 1.8.2
>
> Attachments: AVRO-1965.patch
>
>
> h2. Overview
> In certain scenarios re-parsing a schema constructed via {{SchemaBuilder}} or 
> {{Schema.createRecord}} produces a schema that is no longer equal to the 
> original. In the below example, after parsing the existing schema, the 
> namespace of the top level record is cascaded down to the bottom level 
> record. Note that the way the top level record is being created with the 
> namespace as part of the name {{default.a}} is the same way Hive's 
> {{AvroSerDe}} constructs a schema from a Hive table's metadata.
> h2. Failing test case
> {code}
> Schema d = SchemaBuilder.builder().intType();
> Schema c = 
> SchemaBuilder.record("c").fields().name("d").type(d).noDefault().endRecord();
> Schema b = 
> SchemaBuilder.record("b").fields().name("c").type(c).noDefault().endRecord();
> Schema a1 = 
> SchemaBuilder.record("default.a").fields().name("b").type(b).noDefault().endRecord();
> Schema a2 = new Schema.Parser().parse(a1.toString());
> // a1 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","fields":[{"name":"d","type":"int"}]}}]}}]}
> // a2 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","namespace":"default","fields":[{"name":"d","type":"int"}]}}]}}]}
> assertThat(a2, is(a1));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1965) Reparsing an existing schema mutates the schema

[Doug Cutting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Doug Cutting updated AVRO-1965:
---
 Assignee: Doug Cutting
Fix Version/s: 1.8.2
   Status: Patch Available  (was: Open)

> Reparsing an existing schema mutates the schema
> ---
>
> Key: AVRO-1965
> URL: https://issues.apache.org/jira/browse/AVRO-1965
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: David Maughan
>Assignee: Doug Cutting
>Priority: Minor
> Fix For: 1.8.2
>
> Attachments: AVRO-1965.patch
>
>
> h2. Overview
> In certain scenarios re-parsing a schema constructed via {{SchemaBuilder}} or 
> {{Schema.createRecord}} produces a schema that is no longer equal to the 
> original. In the below example, after parsing the existing schema, the 
> namespace of the top level record is cascaded down to the bottom level 
> record. Note that the way the top level record is being created with the 
> namespace as part of the name {{default.a}} is the same way Hive's 
> {{AvroSerDe}} constructs a schema from a Hive table's metadata.
> h2. Failing test case
> {code}
> Schema d = SchemaBuilder.builder().intType();
> Schema c = 
> SchemaBuilder.record("c").fields().name("d").type(d).noDefault().endRecord();
> Schema b = 
> SchemaBuilder.record("b").fields().name("c").type(c).noDefault().endRecord();
> Schema a1 = 
> SchemaBuilder.record("default.a").fields().name("b").type(b).noDefault().endRecord();
> Schema a2 = new Schema.Parser().parse(a1.toString());
> // a1 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","fields":[{"name":"d","type":"int"}]}}]}}]}
> // a2 = 
> {"type":"record","name":"a","namespace":"default","fields":[{"name":"b","type":{"type":"record","name":"b","namespace":"","fields":[{"name":"c","type":{"type":"record","name":"c","namespace":"default","fields":[{"name":"d","type":"int"}]}}]}}]}
> assertThat(a2, is(a1));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AVRO-1942) Flaky test: TestNettyServerWithCompression.testConnectionsCount

[Gabor Szadovszky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gabor Szadovszky resolved AVRO-1942.

Resolution: Duplicate

Just realized that I've created this issue twice by mistake.

> Flaky test: TestNettyServerWithCompression.testConnectionsCount
> ---
>
> Key: AVRO-1942
> URL: https://issues.apache.org/jira/browse/AVRO-1942
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: Gabor Szadovszky
>Assignee: Gabor Szadovszky
>
> One of the unit tests is often failing in our jenkins environment. However, I 
> was not able to reproduce it on my own environment; it might be related to 
> either the CPU or the network load.
> Stack Trace:
> {code}
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at junit.framework.Assert.assertEquals(Assert.java:205)
>   at 
> org.apache.avro.ipc.TestNettyServer.testConnectionsCount(TestNettyServer.java:152)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1605) Remove Jackson classes from public API

[Gabor Szadovszky (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708893#comment-15708893
 ] 

Gabor Szadovszky commented on AVRO-1605:


What do you think, [~rdblue]?

> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
>Assignee: Gabor Szadovszky
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1961) [JAVA] Generate getters that return an Optional

[Tom White (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708587#comment-15708587
 ] 

Tom White commented on AVRO-1961:
-

For compatibility reasons, I don't think getFoo() should ever return 
Optional. Having getOptionalFoo() is much clearer and safer. Also, I 
noticed that the creator of Optional said "I think routinely using it as a 
return value for getters would definitely be over-use", 
http://stackoverflow.com/a/26328555, so it's not necessarily true that everyone 
will want this feature. In other words, it may never become the default.

Avro allows you to set the directory to load velocity templates from (by 
setting the org.apache.avro.specific.templates system property), so it should 
be possible to try this out with an existing Avro release. You would create a 
copy of the existing templates and change record.vm to have the getOptional*() 
methods.

> [JAVA] Generate getters that return an Optional
> ---
>
> Key: AVRO-1961
> URL: https://issues.apache.org/jira/browse/AVRO-1961
> Project: Avro
>  Issue Type: New Feature
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
>
> A colleague of mine indicated that having getters that return an Optional 
> (java 8 thingy) would be very useful for him.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Status of release 1.8.2??

[Niels Basjes]

Hi,

What is the current status of the new release?
The first RC failed yet I would really like to see it 'out there'.
So what is the status at the moment?

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes