Re: Where should geode example code live

[Jacob Barrett]

+1

On Thu, Nov 10, 2016 at 11:22 AM Swapnil Bawaskar 
wrote:

> +1
>
> On Thu, Nov 10, 2016 at 11:12 AM, Kirk Lund  wrote:
>
> > Yep! Replace "gemfire" with "geode"
> >
> > On Thu, Nov 10, 2016 at 11:07 AM, Kevin Duling 
> wrote:
> >
> > > +1
> > >
> > > Shouldn't that be org.apache.geode.security.examples?
> > >
> > > On Thu, Nov 10, 2016 at 11:03 AM, Jinmei Liao 
> wrote:
> > >
> > > > +1 for both renaming it now and moving it to a separate module going
> > > > forward.
> > > >
> > > > On Thu, Nov 10, 2016 at 10:58 AM, Kirk Lund 
> wrote:
> > > >
> > > > > We have some example code that's not in geode-examples.
> > > > > geode-core-1.0.0-incubating.jar currently contains this package
> with
> > > > > examples:
> > > > >
> > > > > org.geode.gemfire.security.templates
> > > > >
> > > > > Given that template means something a bit different from example,
> I'd
> > > > like
> > > > > to rename this package to examples. Is this acceptable?
> > > > >
> > > > > Going forward, this community needs to spend some considerable
> effort
> > > in
> > > > > improving modularity of geode. The geode-core module should contain
> > > only
> > > > > the bare essentials that are always necessary when using geode.
> > > Optional
> > > > > features and the like should move to their own modules. Along the
> > same
> > > > line
> > > > > of thought, examples should move to geode-examples or some similar
> > > > > sub-module (or even a separate repo). That sub-module should
> > generate a
> > > > jar
> > > > > that can be added to the classpath for purposes of demoing or
> trying
> > > out
> > > > > geode (kicking the tires). I'd like the community to come up with
> > > > > additional ideas on how to facilitate demoing and also make it
> easier
> > > in
> > > > > general to try out geode for the first time.
> > > > >
> > > > > -Kirk
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>

Re: native-client-software-grant - ClientMetadata::getServerLocation

[Jacob Barrett]

Please provide a link to the pull request.

On Wed, Oct 19, 2016 at 11:34 PM Dor Ben Dov  wrote:

> Hi Everyone,
>
> What is the status of this pull request?
>
>
>
> Thanks,
> Dor
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Coding practices/standards

[Jacob Barrett]

+1

On Thu, Oct 13, 2016 at 10:04 AM Kevin Duling  wrote:

> Given that, +1 from me!
>
> On Thu, Oct 13, 2016 at 9:51 AM, Jared Stewart 
> wrote:
>
> > The task is fully suppressible with -x spotlessCheck.  Also, if you have
> > any formatter errors you can automatically fix them with 'gradle
> > spotlessApply’.
> >
> > > On Oct 13, 2016, at 9:40 AM, Kevin Duling  wrote:
> > >
> > > If we made formatting a warning, then people would probably quickly
> > ignore
> > > it.
> > > If we made formatting an error, we need to be sure we don't get in to
> the
> > > situation where 's formatter is not in agreement with
> > the
> > > build's checker.
> > >
> > > I can live with an additional 17 seconds as well.  And Jared's already
> > > reduced the build time locally by 50%.  But I still want the ability to
> > > suppress the check similar to -x javadoc.
> > >
> > > On Wed, Oct 12, 2016 at 9:58 PM, William Markito 
> > > wrote:
> > >
> > >> This sounds really good to me as well.  +1
> > >>
> > >> On Wed, Oct 12, 2016 at 4:13 PM, Jared Stewart 
> > >> wrote:
> > >>
> > >>> This is running locally on my laptop.  Since Spotless is only doing
> > code
> > >>> formatting and not any other static analysis, it already has 0
> errors.
> > >>> (Other than, of course, formatting not consistent with the template.)
> > >>>
> >  On Oct 12, 2016, at 4:11 PM, Kenneth Howe  wrote:
> > 
> >  Agree with Mark, this has to work with 0 errors before it would be
> > >>> useful in precheckin. I think I could live with an additional 17
> > seconds
> > >>> most of the time for running the spotlessCheck as suggested.
> > 
> >  Jared, Is that 17 seconds running locally on your laptop or on a
> more
> > >>> capable machine?
> > 
> >  Ken
> > 
> > > On Oct 12, 2016, at 3:39 PM, Jared Stewart 
> > >> wrote:
> > >
> > > If you want to try it out, I pushed a branch to my Geode repo that
> > >>> contains this change:
> > >
> https://github.com/jaredjstewart/incubator-geode/tree/spotlessPlugin
> > >> <
> > >>> https://github.com/jaredjstewart/incubator-geode/tree/spotlessPlugin
> >
> > >
> > >> On Oct 12, 2016, at 2:27 PM, Darrel Schneider <
> > dschnei...@pivotal.io
> > >>>
> > >>> wrote:
> > >>
> > >> I like Dan's idea of catching formatting issues earlier but I
> think
> > >>> adding
> > >> 5-10 minutes to "build" would be too much. Currently when I'm
> trying
> > >>> to do
> > >> a quick build I use -xjavadoc. I'd probably do the same for this
> > >>> target if
> > >> it was part of build until I'm ready to do a precheckin.
> > >>
> > >> Mark, wouldn't running the formatter on all our java files and
> > >> checking
> > >> them in get these issues down to 0?
> > >>
> > >> On Wed, Oct 12, 2016 at 12:53 PM, Udo Kohlmeyer <
> > >> ukohlme...@pivotal.io
> > 
> > >> wrote:
> > >>
> > >>> +1 - adding checkstyle to precheckin.
> > >>>
> > >>> If the developer uses the provided templates ( eclipse +
> intellij)
> > >>> then
> > >>> most of the formatting issues should be handled before
> precheckin.
> > >>> Also, if
> > >>> a developer has a questionable coding style, that should lessen
> as
> > >>> that
> > >>> developer will have resolve the issues before being able to
> commit.
> > >>>
> > >>> I also believe that this should not be an overbearing and
> intrusive
> > >>> process.
> > >>>
> > >>> --Udo
> > >>>
> > >>>
> > >>>
> > >>> On 13/10/16 6:36 am, Mark Bretl wrote:
> > >>>
> >  Dan,
> > 
> >  There is some extra amount of time, 5-10 minutes extra for the
> > >> entire
> >  project (depending on your CPU). I think the real issue to
> adding
> > >> it
> > >>> to
> >  the
> >  precheckin target and have it be 'effective' is it needs to run
> >  successfully, otherwise it would turn into noise most of the
> time
> > I
> > >>> think.
> >  We need to get the issues down to 0 or manage to set a new
> > baseline
> > >>> (not
> >  the best idea), which is a lot of work, to make it run
> > >> successfully.
> > >>> Right
> >  now, if you run the target, it will fail every time since there
> >  outstanding
> >  issues in the code and very hard to tell what issues were
> > >> introduced.
> > 
> > 
> >  --Mark
> > 
> >  On Wed, Oct 12, 2016 at 11:34 AM, Dan Smith 
> > >>> wrote:
> > 
> >  Seems like it should run as part of the build target. The only
> > >>> reason to
> > > make it part of precheckin is if it takes a long time,
> otherwise
> > >>> people
> > > should get fast feedback they need to change their code before
> > >> they
> > >>> push.
> > >
> > 

Re: Review Request 52641: GEODE-1914 removed old versions of dtds

[Jacob Barrett]

If were are in there changing them all why wouldn't we just change them all
to the latest xsd?

On Fri, Oct 7, 2016 at 10:56 AM Hitesh Khamesra 
wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52641/
> ---
>
> (Updated Oct. 7, 2016, 5:55 p.m.)
>
>
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
>
>
> Changes
> ---
>
> Couple of more changes in cache xmls.
>
>
> Repository: geode
>
>
> Description
> ---
>
> GEODE-1914 Removed old dtds from geode source code(kept 7.0 and above)
>
> Deteted old tests and updated test xmls to point 7.0 dtd
>
>
> Diffs (updated)
> -
>
>   geode-core/src/main/resources/javadoc-images/example-client-cache.xml
> bddeb9f
>   geode-core/src/main/resources/org/apache/geode/admin/doc-files/ds4_0.dtd
> 6566af6
>   geode-core/src/main/resources/org/apache/geode/admin/doc-files/ds5_0.dtd
> d56fd4d
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache3_0.dtd
> 44d42c2
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache4_0.dtd
> d91d50e
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache4_1.dtd
> d64968a
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache5_0.dtd
> 34ca2a9
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache5_1.dtd
> 4a93047
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache5_5.dtd
> 090f7f9
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache5_7.dtd
> 95e54fd
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache5_8.dtd
> dc2ae73
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache6_0.dtd
> 82bdc11
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache6_1.dtd
> 3215fbc
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache6_5.dtd
> 9798748
>
> geode-core/src/main/resources/org/apache/geode/cache/doc-files/cache6_6.dtd
> 0a2c2f2
>
> geode-core/src/test/java/org/apache/geode/cache/RegionFactoryJUnitTest.java
> 9f31eb1
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml30DUnitTest.java
> 187be8a
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml40DUnitTest.java
> 952efb2
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml41DUnitTest.java
> ae1a98d
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml45DUnitTest.java
> 7c10524
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml51DUnitTest.java
> 30925e5
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml55DUnitTest.java
> fd52580
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml57DUnitTest.java
> 833093d
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml58DUnitTest.java
> 4040b15
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml60DUnitTest.java
> 35026ba
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml61DUnitTest.java
> ea15c18
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml65DUnitTest.java
> a12737b
>
> geode-core/src/test/java/org/apache/geode/cache30/CacheXml66DUnitTest.java
> ededb8d
>
> geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java
> 31a72c8
>
> geode-core/src/test/java/org/apache/geode/pdx/PdxSerializableJUnitTest.java
> 21accef
>   geode-core/src/test/resources/jta/cachejta.xml 9a36ee6
>
> geode-core/src/test/resources/org/apache/geode/cache/client/ClientCacheFactoryJUnitTest_single_pool.xml
> 92454c4
>
> geode-core/src/test/resources/org/apache/geode/cache/query/functional/index-creation-with-eviction.xml
> 861bb23
>
> geode-core/src/test/resources/org/apache/geode/cache/query/functional/index-creation-without-eviction.xml
> f8bdc78
>
> geode-core/src/test/resources/org/apache/geode/cache/query/functional/index-recovery-overflow.xml
> 4ca5e2f
>
> geode-core/src/test/resources/org/apache/geode/cache/query/internal/index/cachequeryindex.xml
> ebcc0a4
>
> geode-core/src/test/resources/org/apache/geode/cache/query/internal/index/cachequeryindexwitherror.xml
> caa3cc9
>
> geode-core/src/test/resources/org/apache/geode/cache/query/partitioned/PRIndexCreation.xml
> 4236a7d
>
> geode-core/src/test/resources/org/apache/geode/cache30/attributesUnordered.xml
> aa8c3f4
>   geode-core/src/test/resources/org/apache/geode/cache30/badFloat.xml
> 883216c
>   geode-core/src/test/resources/org/apache/geode/cache30/badInt.xml 17f9aa1
>
> geode-core/src/test/resources/org/apache/geode/cache30/badKeyConstraintClass.xml
> 9aa8cb3
>   geode-core/src/test/resources/org/apache/geode/cache30/badScope.xml
> 0744a72
>
> geode-core/src/test/resources/org/apache/geode/cache30/callbackNotDeclarable.xml
> fb3cf9c
>
> geode-core/src/test/resources/org/apache/geode/cache30/callbackWithException.xml
> 4a39cc1
>   

Re: backward compatibility testing against GemFire 8.x WAN/clients

[Jacob Barrett]

-1
Completely agree with Mark on this.


On Thu, Oct 6, 2016 at 9:31 AM Mark Bretl  wrote:

> -1 for this
>
> I do understand the intent and reason behind this, however, in addition to
> the reasons Anthony provided, I do not believe this community should carry
> the burden of testing compatibility with proprietary/commercial software.
> Even though Geode has its history in GemFire, I can only see the community
> supporting official Geode releases. It would set a bad precedent to allow
> for any part of the Geode code ( source or test ) to depend on any
> commercial code.
>
> If any company wants to make sure their software works with Geode, it is
> their responsibility.
>
> My $.02,
>
> --Mark
>
> On Thu, Oct 6, 2016 at 9:12 AM, Bruce Schuchardt 
> wrote:
>
> > Yes, dist.gemstone.com.
> >
> >
> > Le 10/6/2016 à 9:08 AM, Dick Cavender a écrit :
> >
> >> Only on initial setup/access to repo.pivotal.io is the EULA acceptance
> >> required. After that you should be able to pull from any repo there
> without
> >> interaction but you will need to provide the creds as part of the pull.
> >>
> >> Are you instead using dist.gemstone.com for the older jars which is the
> >> original repo that lives in the spring s3 repo
> >>
> >>
> >> On 10/6/2016 7:48 AM, Bruce Schuchardt wrote:
> >>
> >>> Thanks Anthony.
> >>>
> >>> I thought there was some interest in supporting old GemFire clients and
> >>> WAN.  Is there no way to download it without a login/EULA?  I'm
> currently
> >>> using a different repo but maybe that's only available in Pivotal's
> network.
> >>>
> >>> As far as M3 goes, do you think there would be any value in testing
> >>> against it?  I don't want to introduce new tests unless they are
> helpful.
> >>>
> >>> Le 10/5/2016 à 5:31 PM, Anthony Baker a écrit :
> >>>
>  Given that the official Pivotal maven repo [1] is locked behind a
> login
>  and a EULA I think this might not work so well.  The license
> compatibility
>  issues would need to be explored as well.
> 
>  How would you feel about testing backwards compatibility against
>  1.0.0-incubating.M3?
> 
>  Anthony
> 
>  [1] http://commercial-repo.pivotal.io
> 
>  On Oct 5, 2016, at 4:17 PM, Bruce Schuchardt 
> > wrote:
> >
> > We now have a backward-compatibility module but it's not well tested.
> > I'd
> > like to add tests to this module that run against GemFire jars
> > downloaded
> > from the Pivotal maven repository.  I've already implemented the
> > framework
> > and some smoke tests but want to know how people feel about the tests
> > downloading something proprietary to test against and whether
> failures
> > would be something the community cares about.
> >
> > If we don't want this I'll keep it out of the repo until we have a
> > 1.0.0
> > release to test against.
> >
> 
> >>>
> >>
> >
>

Re: Previous versions dtds

[Jacob Barrett]

The files MUST remain in the source otherwise the validating parser will
have to download them from the website. This is VERY slow and only works if
you have Internet access. The schema resolver first looks in the class path
then to the web.

-Jake


On Thu, Sep 29, 2016 at 2:24 PM Anthony Baker  wrote:

> Any active dtd's or schema’s should be hosted near to
> http://geode.apache.org/schema/cache/.  If you follow the directions [1]
> to update the website it’s not too hard.
>
> Can we remove the pivotal.io schema from source?
>
> ./geode-core/src/main/resources/META-INF/schemas/
> schema.pivotal.io/gemfire/cache/cache-8.1.xsd
>
> We should upload the lucene scheme to the website also:
> ./geode-lucene/src/main/resources/META-INF/schemas/
> geode.apache.org/lucene/lucene-1.0.xsd
>
>
> Anthony
>
> [1]
> https://github.com/apache/incubator-geode/blob/develop/geode-site/website/README.md
>
>
> > On Sep 29, 2016, at 2:15 PM, Darrel Schneider 
> wrote:
> >
> > statisticsType.dtd is used
> > by org.apache.geode.StatisticsTypeFactory.createTypesFromXml(Reader)
> > See the javadocs on StatisticsTypeFactory for an example of how to use
> it.
> >
> > On Thu, Sep 29, 2016 at 1:50 PM, Kirk Lund  wrote:
> >
> >> I'm actually unfamiliar with statisticsType.dtd:
> >>
> >> geode-core/src/main/resources/org/apache/geode/statisticsType.dtd
> >>
> >> I notice it still references GemStone and gemstone.com. Do we have
> copies
> >> of the dtds on geode.apache.org? Where should these dtds live online?
> >>
> >> Thanks,
> >> Kirk
> >>
> >>
> >> On Thu, Sep 29, 2016 at 9:37 AM, Hitesh Khamesra <
> >> hitesh...@yahoo.com.invalid> wrote:
> >>
> >>> We have following dtds in geode source code. We were thinking to remove
> >>> previous versions(1.0 to 6.6) of dtds.Please let us know if there is
> any
> >>> concern on  this.
> >>>
> >>> ./main/resources/org/apache/geode/admin/doc-files/ds4_0.dtd
> >>> ./main/resources/org/apache/geode/admin/doc-files/ds5_0.dtd
> >>> ./main/resources/org/apache/geode/admin/jmx/internal/doc-
> >>> files/mbeans-descriptors.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache3_0.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache4_0.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache4_1.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_0.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_1.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_5.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_7.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_8.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_0.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_1.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_5.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_6.dtd
> >>>
> >>>
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache7_0.dtd
> >>> ./main/resources/org/apache/geode/cache/doc-files/cache8_0.dtd
> >>> ./main/resources/org/apache/geode/statisticsType.dtd
> >>>
> >>> Thanks.HItesh
> >>>
> >>>
> >>
>
>

Re: Limiting scope for Geode 1.0

[Jacob Barrett]

+1 for creating branch now to prevent feature creep.

On Thu, Sep 29, 2016 at 2:10 PM Kirk Lund  wrote:

> I think we should propose creating that release branch sooner (now?) so we
> can minimize unplanned changes slipping into 1.0 and destabilizing it.
>
> -Kirk
>
> On Thursday, September 29, 2016, Anthony Baker  wrote:
>
> > Using the gitflow approach, we cut a release/1.0.0 branch to isolate the
> > release branch from ongoing development.  For past releases we have
> waited
> > as long as possible to cut the branch to minimize overhead.  Perhaps this
> > time we should create the branch earlier.
> >
> > JIRA shows the open issues for 1.0.0 [1] but there are some deltas
> > compared to the last release scope email [2].
> >
> > GEODE-17 / GEODE-1570 was mentioned as a possible candidate for 1.0.0 but
> > the Fix Version is not set
> > GEODE-1168 was not included in the 1.0.0 scope discussions but Fix
> Version
> > is set to 1.0.0
> > GEODE-1914 is follow on work from the package namespace changes
> >
> > @Swapnil, does this accurately reflect the scope discussions for 1.0.0?
> > If so, I can update the bugs.
> >
> > Anthony
> >
> > [1] https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20GEODE%20AND%20fixVersion%20%3D%201.0.0-incubating%
> > 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
> > 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > [2] http://mail-archives.apache.org/mod_mbox/incubator-geode-
> > dev/201609.mbox/%3cCANZq1gBzMTEM_JHzw2YT_LZeC5g472XkNCfJhma76xah=Yyq6A@
> > mail.gmail.com%3e
> >
> >
> > > On Sep 29, 2016, at 1:02 PM, Kirk Lund  >
> > wrote:
> > >
> > > What changes are we still waiting on to cut the next RC of Geode 1.0?
> > >
> > > Is there a way to create a branch for Geode 1.0 develop that allows
> folks
> > > to continue working on post-1.0 features or bug fixes without
> > destabilizing
> > > Geode 1.0? This way, only the necessary changes for Geode 1.0 would go
> to
> > > the 1.0 branch?
> > >
> > > -Kirk
> >
> >
>

Re: Previous versions dtds

[Jacob Barrett]

I think you should drop all the GemFire DTDs from Geode.

Geode doesn't need to be tainted with reading old GemFire configuration
files. It is very simple for someone to update their XML to the Geode XSD.



On Thu, Sep 29, 2016 at 2:15 PM Darrel Schneider 
wrote:

> statisticsType.dtd is used
> by org.apache.geode.StatisticsTypeFactory.createTypesFromXml(Reader)
> See the javadocs on StatisticsTypeFactory for an example of how to use it.
>
> On Thu, Sep 29, 2016 at 1:50 PM, Kirk Lund  wrote:
>
> > I'm actually unfamiliar with statisticsType.dtd:
> >
> > geode-core/src/main/resources/org/apache/geode/statisticsType.dtd
> >
> > I notice it still references GemStone and gemstone.com. Do we have
> copies
> > of the dtds on geode.apache.org? Where should these dtds live online?
> >
> > Thanks,
> > Kirk
> >
> >
> > On Thu, Sep 29, 2016 at 9:37 AM, Hitesh Khamesra <
> > hitesh...@yahoo.com.invalid> wrote:
> >
> > > We have following dtds in geode source code. We were thinking to remove
> > > previous versions(1.0 to 6.6) of dtds.Please let us know if there is
> any
> > > concern on  this.
> > >
> > > ./main/resources/org/apache/geode/admin/doc-files/ds4_0.dtd
> > > ./main/resources/org/apache/geode/admin/doc-files/ds5_0.dtd
> > > ./main/resources/org/apache/geode/admin/jmx/internal/doc-
> > > files/mbeans-descriptors.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache3_0.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache4_0.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache4_1.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache5_0.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache5_1.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache5_5.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache5_7.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache5_8.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache6_0.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache6_1.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache6_5.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache6_6.dtd
> > >
> > >
> > > ./main/resources/org/apache/geode/cache/doc-files/cache7_0.dtd
> > > ./main/resources/org/apache/geode/cache/doc-files/cache8_0.dtd
> > > ./main/resources/org/apache/geode/statisticsType.dtd
> > >
> > > Thanks.HItesh
> > >
> > >
> >
>

Re: Unit testing classes that depend on static collaborators

[Jacob Barrett]

Security is one of those exceptions to the rules about ThreadLocal. Almost
every implementation uses ThreadLocal to stash the current executing
context. Generally then there is a static class that gets the current
context. To test you should be able to just push your own mocked context
into the context. Not familiar with Shiro but I have done this with a few
other JAAS implementations.

-Jake


On Mon, Jul 25, 2016 at 5:33 PM Jinmei Liao  wrote:

> Shiro relies heavily on ThreadLocal. GeodeSecurityUtils is a wrapper around
> Shiro. That's where all the static usage stems from. There is a trade-off
> if we pass some sort session object around: calling code would need to keep
> a reference of it and knows when/where/which to pass it down.
>
> On Mon, Jul 25, 2016 at 5:21 PM, Dan Smith  wrote:
>
> > IMHO static helper methods like those in Bytes are fine. We would never
> > want to substitute a mock implementation of one of those methods and they
> > don't have any collaborators.
> >
> > Just glancing at GeodeSecurityUtils, what I don't like is that it's
> relying
> > heavily on mutable static singletons (securityManager, postProcessor) and
> > thread locals. I think we should avoid using singletons and thread locals
> > in geode code, because it's too easy to leave junk lying around and it
> also
> > makes code hard to test. In this case maybe it would make more sense to
> > pass some sort of session object around?
> >
> > -Dan
> >
> > On Mon, Jul 25, 2016 at 4:26 PM, Kirk Lund  wrote:
> >
> > > I was trying to describe any Java class in Geode which provides feature
> > > functionality that should be unit tested and integration tested, but is
> > > either currently implemented as a static class or which collaborates
> > with a
> > > non-trivial component currently implemented as a static class.
> > >
> > > I wasn't describing the simple static classes like Byte, StringUtils,
> > > IOUtils. These are trivial and not generally considered to be an
> > important
> > > collaborator requiring a mock.
> > >
> > > Using Mockito allows us to test the interaction between a class under
> > test
> > > and its collaborators. To facilitate this, we need the collaborator to
> be
> > > defined as an interface or abstract class.
> > >
> > > This specifically came about on my team because we have been unit
> testing
> > > GMSAuthenticator and lots of Client Commands that interact with
> > Integrated
> > > Security. We want to include unit tests to verify that the class under
> > test
> > > correctly interacts with its collaborators including Integrated
> Security
> > > (GEODE-17). For this reason, we want to transform GeodeSecurityUtil
> into
> > a
> > > non-static class that implements an interface that can be mocked.
> > >
> > > Hopefully everyone agrees that we need to make a concerted effort to
> > write
> > > lots of new fast-running unit tests that use mocks. This includes old
> and
> > > new code.
> > >
> > > In general, actual features implemented in static classes is common in
> > > Geode but it inhibits unit testing and thus should change as we
> refactor
> > > the code towards testability.
> > >
> > > This thread started as me describing a simple pattern to facilitate
> unit
> > > testing against static classes that for whatever reason, we want to
> hold
> > > off refactoring them but we don't want to hold off writing unit tests
> for
> > > them as an important collaborator class.
> > >
> > > Does this make sense? Is everyone on the same page regarding the value
> of
> > > unit testing and refactoring to testability & maintainability?
> > >
> > > -Kirk
> > >
> > > On Wednesday, July 20, 2016, Anthony Baker  wrote:
> > >
> > > > Great discussion!  I’ve got two questions:
> > > >
> > > > 1) What do you think of Bytes.java
> > > > (:geode-core:com.gemstone.gemfire.internal.util)?  Is it a reasonable
> > use
> > > > of the Helper / Utility class pattern?  If not, how would you change
> > it?
> > > > Creating a new instance for each use seems inefficient and using a
> > > > Singleton is just a different way to do statics.
> > > >
> > > > 2) Is GeodeSecurityUtil of the same category as Bytes.java or is it
> > > > something more?
> > > >
> > > > Anthony
> > > >
> > > >
> > > > > On Jul 20, 2016, at 10:41 AM, Jinmei Liao  > > > > wrote:
> > > > >
> > > > > Wouldn't the change be too intrusive? Now any class that uses
> > security
> > > > > would need to have this additional constructor, and if a no-arg
> > > > constructor
> > > > > is available, it's error prone that the class will be used without
> > > > > security, and if we delete the no-arg constructor, that would
> cause a
> > > lot
> > > > > of chain reaction.
> > > > >
> > > > > The usage of shiro itself is static (all the state information is
> in
> > > the
> > > > > thread), which, in my opinion is one of the selling points of Shiro
> > > since
> > > > > 

Re: Snappy compressor (native->java)

[Jacob Barrett]

+1 for pure java default and making the native a drop in option.

I would suggest looking into embedding the native bits into a JAR file.
There are some tricks you can do to write the native bits out to disk from
the JAR file to load them at runtime. This would make it easier for someone
to deploy the speedup by just dropping in a single JAR into the class path.

-Jake


On Mon, Jun 20, 2016 at 4:14 PM Sai Boorlagadda 
wrote:

> Geode currently bundles xerial/snappy
>  as a default implementation. And
> this is a "JNI wrapper" on google snappy 
> implementation.
>
> "xerial/snappy" jar bundles several pre-compiled static libraries to
> support various OS (linux, windows, SunOS) and architectures (x86, Sparc
> etc). The current dependency (1.1.1.6) does not support SunOS (Sparc), so
> the plan is to upgrade to a more recent version.
>
> While upgrading to a more recent version, I found a pure java port
>  of original C++ implementation and wanted
> to swap with use pure java implementation to avoid any platform specific
> dependency on Geode.
>
> From the creator - "*the pure Java port is 20-30% faster for block
> compress, 0-10% slower for block uncompress, and 0-5% slower for round-trip
> block compression.*".
>
> Though native version is better on uncompress (more number of gets, puts
> depending on use cases), I would still vote for distributing with a pure
> java version as a "default" implementation as Geode already exposes an
> interface to allow any one to provide any custom implementation.
>
> In case if there are any differences between these two implementations,
> swapping with a pure java version should not impact any existing users, as
> Geode does not save compressed data to disk or on to the wire.
>
> Let me know if any one has different thoughts?
>
> Sai
>

Re: update website for WAN, CQ and native client

[Jacob Barrett]

-1

I would not mention native clients yet since they aren't anywhere near a
state to be built and used.
On Thu, Jun 16, 2016 at 5:32 AM yang theseus  wrote:

> +1 great!
>
> 2016-06-16 15:14 GMT+08:00 Gregory Chase :
>
> > +1
> >
> > On Wed, Jun 15, 2016 at 11:27 PM, Swapnil Bawaskar  >
> > wrote:
> >
> > > Hi,
> > > WAN and CQ were the major features of M2 release[1]. Also, Native
> client
> > > has been donated to apache [2]. Considering these new features, I would
> > > like to update the geode website [3] <
> http://geode.incubator.apache.org/
> > >
> > > and add these new features as captured in this image [4]
> > > .
> > >
> > > Thanks!
> > > Swapnil.
> > >
> > > [1]
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334709
> > > [2]
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201605.mbox/%3CCAEwge-ENhF4s_k5Y%3Dh9-mNFANb777j8bNDe4U9jahPYim61pfg%40mail.gmail.com%3E
> > > [3] http://geode.incubator.apache.org/
> > > [4] http://i.imgur.com/3Jad68K.png
> > >
> >
> >
> >
> > --
> > Greg Chase
> >
> > Global Head, Big Data Communities
> > http://www.pivotal.io/big-data
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> > Blog: http://geekmarketing.biz/
> >
>

Re: c++ native client

[Jacob Barrett]

The current version of the commercially available native client is 8.2.1.
The open source code is closest to that 8.2 but newer with some changes. It
will commercially be known as 9.0.
On Sun, Jun 5, 2016 at 12:31 AM Dor Ben Dov <dor.ben-...@amdocs.com> wrote:

> Jacob
> As far as I know, unless I am wrong, the current native client (before
> your switched it to the open source) was 7.0.1.
> Is this the same 7.0.1 ?
>
> Dor
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: יום ו 03 יוני 2016 17:24
> To: dev@geode.incubator.apache.org
> Subject: Re: c++ native client
>
> The native client in geode will likely be v1 to match the Java bits, or
> whatever geode version is when nc is ready to release with geode.
> On Fri, Jun 3, 2016 at 7:18 AM Dor Ben Dov <dor.ben-...@amdocs.com> wrote:
>
> > Hi,
> >
> > Anyone can tell me what is the version of the native client (c++) ?
> >
> > Dor
> >
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement, you may
> > review at http://www.amdocs.com/email_disclaimer.asp
> >
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: c++ native client

[Jacob Barrett]

The native client in geode will likely be v1 to match the Java bits, or
whatever geode version is when nc is ready to release with geode.
On Fri, Jun 3, 2016 at 7:18 AM Dor Ben Dov  wrote:

> Hi,
>
> Anyone can tell me what is the version of the native client (c++) ?
>
> Dor
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: c++ native client memory management

[Jacob Barrett]

We do not use an external memory manager.

On Tue, May 31, 2016 at 8:14 AM Gal Palmery  wrote:

> Hi,
>
> Do you use a specific external memory manager (like mtmalloc, hoard,
> etc..) for native-client code?
>
> Thanks,
> Gal
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: MultiAxisChartFX and jvsd

[Jacob Barrett]

I don't see the contradiction. MultiAxisChartFX is GPL with class path
exception like the JDK. It cannot be relicensed to Apache 2.0. Per ASF
rules it may not be shipped as part of the binary distribution either. The
library can be downloaded separately, like the JDK, to run the jVSD
application.

On Tue, May 10, 2016 at 11:26 AM Dor Ben Dov <dor.ben-...@amdocs.com> wrote:

> Jacob
> This is different answer than already being given here by Juan
> " Hey Dor,
>
> According to Jens (from the mail list history):
> The MultiAxisChartFX class is GPL code and cannot have an Apache 2.0
> license attached to it. This is the reason this code was in a separate
> repo. A
> user would need to build that separately and then reference it in this
> project."
>
> Hope this helps.
> Best regards."
>
> Unless I am missing something, there is a contradiction between.
> Dor
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: יום ג 10 מאי 2016 19:55
> To: dev@geode.incubator.apache.org
> Subject: Re: MultiAxisChartFX and jvsd
>
> BTW, the jVSD is apache 2 licensed. It is dependent on the JRE, like all
> other java products. The JavaFX, included with the JRE, is licensed the
> same as the JRE. The MultiAxisChartFX is licensed the same as the JRE. The
> plan is to work the changes in the chart library into the JavaFX project.
>
>
> On Tue, May 10, 2016 at 9:53 AM Jacob Barrett <jbarr...@pivotal.io> wrote:
>
> > Are you suggesting that it be a desktop app rendering HTML 5 / JS or a
> > web application?
> >
> > On Tue, May 10, 2016 at 9:49 AM Dor Ben Dov <dor.ben-...@amdocs.com>
> > wrote:
> >
> >> Maybe replacing it with html 5, I am not saying it's 5 min work of
> >> course. But this way it will allow including it in the main line -
> >> develop / trunk branch and continue being apache license 2 - without
> >> any dependency issues.
> >> Again, it's not 5min solution of course.
> >> Dor
> >>
> >> -Original Message-
> >> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> >> Sent: יום ג 10 מאי 2016 19:47
> >> To: dev@geode.incubator.apache.org
> >> Subject: Re: MultiAxisChartFX and jvsd
> >>
> >> Do you have a suggestion for a better graphing package in Java?
> >> JavaFX graphing library is very fast and extensible.
> >>
> >> On Tue, May 10, 2016 at 9:45 AM Dor Ben Dov <dor.ben-...@amdocs.com>
> >> wrote:
> >>
> >> > Any news on the jVSD and when it will be merged to the main branch ?
> >> > Any thought maybe to replace the javafx with different solution maybe
> ?
> >> >
> >> > Thanks
> >> > Dor
> >> > -Original Message-
> >> > From: Daniel Farcovich
> >> > Sent: יום ג 10 מאי 2016 08:37
> >> > To: Jacob Barrett
> >> > Cc: dev@geode.incubator.apache.org
> >> > Subject: RE: MultiAxisChartFX and jvsd
> >> >
> >> > Hi Jake,
> >> > Do you know when is jVSD going to be merged into the develop branch?
> >> >
> >> > Thanks,
> >> > Daniel
> >> >
> >> > -Original Message-
> >> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> >> > Sent: Monday, May 09, 2016 6:09 PM
> >> > To: dev@geode.incubator.apache.org
> >> > Subject: Re: MultiAxisChartFX and jvsd
> >> >
> >> > A complete rewrite of MultiAxisChartFX is not planned. The
> >> > MultiAxisChartFX is derived from the OpenJDK XYChart and carries
> >> > the same GPL with class path exception that the JDK does. The plan
> >> > is to merge jVSD into the develop branch with the dependency as is.
> >> > The binary distribution will not contain the dependency. On first
> >> > execution of jVSD it will prompt and download the dependency.
> >> >
> >> > -Jake
> >> >
> >> >
> >> > On Sun, May 8, 2016 at 8:10 AM Daniel Farcovich <
> >> > daniel.farcov...@amdocs.com>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Is jvsd going to be merged to the main branch anytime soon?
> >> > >
> >> > > Will MultiAxisChartFX class be replaced by another class which
> >> > > complies with Apache 2.0 license?
> >> > >
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Daniel
> 

Re: MultiAxisChartFX and jvsd

[Jacob Barrett]

BTW, the jVSD is apache 2 licensed. It is dependent on the JRE, like all
other java products. The JavaFX, included with the JRE, is licensed the
same as the JRE. The MultiAxisChartFX is licensed the same as the JRE. The
plan is to work the changes in the chart library into the JavaFX project.


On Tue, May 10, 2016 at 9:53 AM Jacob Barrett <jbarr...@pivotal.io> wrote:

> Are you suggesting that it be a desktop app rendering HTML 5 / JS or a web
> application?
>
> On Tue, May 10, 2016 at 9:49 AM Dor Ben Dov <dor.ben-...@amdocs.com>
> wrote:
>
>> Maybe replacing it with html 5, I am not saying it's 5 min work of
>> course. But this way it will allow including it in the main line - develop
>> / trunk branch and continue being apache license 2 - without any dependency
>> issues.
>> Again, it's not 5min solution of course.
>> Dor
>>
>> -Original Message-
>> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
>> Sent: יום ג 10 מאי 2016 19:47
>> To: dev@geode.incubator.apache.org
>> Subject: Re: MultiAxisChartFX and jvsd
>>
>> Do you have a suggestion for a better graphing package in Java? JavaFX
>> graphing library is very fast and extensible.
>>
>> On Tue, May 10, 2016 at 9:45 AM Dor Ben Dov <dor.ben-...@amdocs.com>
>> wrote:
>>
>> > Any news on the jVSD and when it will be merged to the main branch ?
>> > Any thought maybe to replace the javafx with different solution maybe ?
>> >
>> > Thanks
>> > Dor
>> > -Original Message-
>> > From: Daniel Farcovich
>> > Sent: יום ג 10 מאי 2016 08:37
>> > To: Jacob Barrett
>> > Cc: dev@geode.incubator.apache.org
>> > Subject: RE: MultiAxisChartFX and jvsd
>> >
>> > Hi Jake,
>> > Do you know when is jVSD going to be merged into the develop branch?
>> >
>> > Thanks,
>> > Daniel
>> >
>> > -Original Message-
>> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
>> > Sent: Monday, May 09, 2016 6:09 PM
>> > To: dev@geode.incubator.apache.org
>> > Subject: Re: MultiAxisChartFX and jvsd
>> >
>> > A complete rewrite of MultiAxisChartFX is not planned. The
>> > MultiAxisChartFX is derived from the OpenJDK XYChart and carries the
>> > same GPL with class path exception that the JDK does. The plan is to
>> > merge jVSD into the develop branch with the dependency as is. The
>> > binary distribution will not contain the dependency. On first
>> > execution of jVSD it will prompt and download the dependency.
>> >
>> > -Jake
>> >
>> >
>> > On Sun, May 8, 2016 at 8:10 AM Daniel Farcovich <
>> > daniel.farcov...@amdocs.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > Is jvsd going to be merged to the main branch anytime soon?
>> > >
>> > > Will MultiAxisChartFX class be replaced by another class which
>> > > complies with Apache 2.0 license?
>> > >
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Daniel
>> > >
>> > >
>> > >
>> > > *From:* Juan José Ramos [mailto:jra...@pivotal.io
>> > > <jra...@pivotal.io>]
>> > > *Sent:* יום ד 06 אפריל 2016 10:56
>> > > *To:* u...@geode.incubator.apache.org
>> > > *Subject:* Re: geode in maven repository
>> > >
>> > >
>> > >
>> > > Hey Dor,
>> > >
>> > >
>> > >
>> > > According to Jens (from the mail list history):
>> > >
>> > > *The MultiAxisChartFX class is GPL code and cannot have an Apache
>> > > 2.0 license attached to it. This is the reason this code was in a
>> > > separate repo. A*
>> > >
>> > > *user would need to build that separately and then reference it in
>> > > this
>> > > project."*
>> > >
>> > >
>> > >
>> > > Hope this helps.
>> > >
>> > > Best regards.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Apr 6, 2016 at 8:36 AM, Dor Ben Dov <dor.ben-...@amdocs.com>
>> > > wrote:
>> > >
>> > > Do you remember which dep’ is preventing it from being Apache license
>> 2 ?
>> > >
>> > > Maybe it’s something –we as community can do ?
>> > >
>> > >
>> > >
>>

Re: MultiAxisChartFX and jvsd

[Jacob Barrett]

Are you suggesting that it be a desktop app rendering HTML 5 / JS or a web
application?

On Tue, May 10, 2016 at 9:49 AM Dor Ben Dov <dor.ben-...@amdocs.com> wrote:

> Maybe replacing it with html 5, I am not saying it's 5 min work of course.
> But this way it will allow including it in the main line - develop / trunk
> branch and continue being apache license 2 - without any dependency issues.
> Again, it's not 5min solution of course.
> Dor
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: יום ג 10 מאי 2016 19:47
> To: dev@geode.incubator.apache.org
> Subject: Re: MultiAxisChartFX and jvsd
>
> Do you have a suggestion for a better graphing package in Java? JavaFX
> graphing library is very fast and extensible.
>
> On Tue, May 10, 2016 at 9:45 AM Dor Ben Dov <dor.ben-...@amdocs.com>
> wrote:
>
> > Any news on the jVSD and when it will be merged to the main branch ?
> > Any thought maybe to replace the javafx with different solution maybe ?
> >
> > Thanks
> > Dor
> > -Original Message-
> > From: Daniel Farcovich
> > Sent: יום ג 10 מאי 2016 08:37
> > To: Jacob Barrett
> > Cc: dev@geode.incubator.apache.org
> > Subject: RE: MultiAxisChartFX and jvsd
> >
> > Hi Jake,
> > Do you know when is jVSD going to be merged into the develop branch?
> >
> > Thanks,
> > Daniel
> >
> > -Original Message-
> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > Sent: Monday, May 09, 2016 6:09 PM
> > To: dev@geode.incubator.apache.org
> > Subject: Re: MultiAxisChartFX and jvsd
> >
> > A complete rewrite of MultiAxisChartFX is not planned. The
> > MultiAxisChartFX is derived from the OpenJDK XYChart and carries the
> > same GPL with class path exception that the JDK does. The plan is to
> > merge jVSD into the develop branch with the dependency as is. The
> > binary distribution will not contain the dependency. On first
> > execution of jVSD it will prompt and download the dependency.
> >
> > -Jake
> >
> >
> > On Sun, May 8, 2016 at 8:10 AM Daniel Farcovich <
> > daniel.farcov...@amdocs.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Is jvsd going to be merged to the main branch anytime soon?
> > >
> > > Will MultiAxisChartFX class be replaced by another class which
> > > complies with Apache 2.0 license?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Daniel
> > >
> > >
> > >
> > > *From:* Juan José Ramos [mailto:jra...@pivotal.io
> > > <jra...@pivotal.io>]
> > > *Sent:* יום ד 06 אפריל 2016 10:56
> > > *To:* u...@geode.incubator.apache.org
> > > *Subject:* Re: geode in maven repository
> > >
> > >
> > >
> > > Hey Dor,
> > >
> > >
> > >
> > > According to Jens (from the mail list history):
> > >
> > > *The MultiAxisChartFX class is GPL code and cannot have an Apache
> > > 2.0 license attached to it. This is the reason this code was in a
> > > separate repo. A*
> > >
> > > *user would need to build that separately and then reference it in
> > > this
> > > project."*
> > >
> > >
> > >
> > > Hope this helps.
> > >
> > > Best regards.
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 6, 2016 at 8:36 AM, Dor Ben Dov <dor.ben-...@amdocs.com>
> > > wrote:
> > >
> > > Do you remember which dep’ is preventing it from being Apache license
> 2 ?
> > >
> > > Maybe it’s something –we as community can do ?
> > >
> > >
> > >
> > > Dor
> > >
> > >
> > >
> > > *From:* Juan José Ramos [mailto:jra...@pivotal.io]
> > > *Sent:* יום ד 06 אפריל 2016 10:30
> > > *To:* u...@geode.incubator.apache.org
> > > *Subject:* Re: geode in maven repository
> > >
> > >
> > >
> > > Hi Dor,
> > >
> > >
> > >
> > > As my understanding, the project MultiAxisChart doesn't use the
> > > apache license and that's the reason is not even included in the
> > > development branch, so we shouldn't modify the project and include
> > > it as part of
> > Geode.
> > > In the short term we should get rid of the dependency to that
> > > project and right now we are only using it as it is.
> > >
>

Re: MultiAxisChartFX and jvsd

[Jacob Barrett]

Do you have a suggestion for a better graphing package in Java? JavaFX
graphing library is very fast and extensible.

On Tue, May 10, 2016 at 9:45 AM Dor Ben Dov <dor.ben-...@amdocs.com> wrote:

> Any news on the jVSD and when it will be merged to the main branch ?
> Any thought maybe to replace the javafx with different solution maybe ?
>
> Thanks
> Dor
> -Original Message-
> From: Daniel Farcovich
> Sent: יום ג 10 מאי 2016 08:37
> To: Jacob Barrett
> Cc: dev@geode.incubator.apache.org
> Subject: RE: MultiAxisChartFX and jvsd
>
> Hi Jake,
> Do you know when is jVSD going to be merged into the develop branch?
>
> Thanks,
> Daniel
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, May 09, 2016 6:09 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: MultiAxisChartFX and jvsd
>
> A complete rewrite of MultiAxisChartFX is not planned. The
> MultiAxisChartFX is derived from the OpenJDK XYChart and carries the same
> GPL with class path exception that the JDK does. The plan is to merge jVSD
> into the develop branch with the dependency as is. The binary distribution
> will not contain the dependency. On first execution of jVSD it will prompt
> and download the dependency.
>
> -Jake
>
>
> On Sun, May 8, 2016 at 8:10 AM Daniel Farcovich <
> daniel.farcov...@amdocs.com>
> wrote:
>
> > Hi,
> >
> > Is jvsd going to be merged to the main branch anytime soon?
> >
> > Will MultiAxisChartFX class be replaced by another class which
> > complies with Apache 2.0 license?
> >
> >
> >
> > Thanks,
> >
> > Daniel
> >
> >
> >
> > *From:* Juan José Ramos [mailto:jra...@pivotal.io <jra...@pivotal.io>]
> > *Sent:* יום ד 06 אפריל 2016 10:56
> > *To:* u...@geode.incubator.apache.org
> > *Subject:* Re: geode in maven repository
> >
> >
> >
> > Hey Dor,
> >
> >
> >
> > According to Jens (from the mail list history):
> >
> > *The MultiAxisChartFX class is GPL code and cannot have an Apache 2.0
> > license attached to it. This is the reason this code was in a separate
> > repo. A*
> >
> > *user would need to build that separately and then reference it in
> > this
> > project."*
> >
> >
> >
> > Hope this helps.
> >
> > Best regards.
> >
> >
> >
> >
> >
> > On Wed, Apr 6, 2016 at 8:36 AM, Dor Ben Dov <dor.ben-...@amdocs.com>
> > wrote:
> >
> > Do you remember which dep’ is preventing it from being Apache license 2 ?
> >
> > Maybe it’s something –we as community can do ?
> >
> >
> >
> > Dor
> >
> >
> >
> > *From:* Juan José Ramos [mailto:jra...@pivotal.io]
> > *Sent:* יום ד 06 אפריל 2016 10:30
> > *To:* u...@geode.incubator.apache.org
> > *Subject:* Re: geode in maven repository
> >
> >
> >
> > Hi Dor,
> >
> >
> >
> > As my understanding, the project MultiAxisChart doesn't use the apache
> > license and that's the reason is not even included in the development
> > branch, so we shouldn't modify the project and include it as part of
> Geode.
> > In the short term we should get rid of the dependency to that project
> > and right now we are only using it as it is.
> >
> > Cheers.
> >
> >
> >
> >
> >
> > On Tue, Apr 5, 2016 at 6:19 PM, Dor Ben Dov <dor.ben-...@amdocs.com>
> > wrote:
> >
> > Jens,
> >
> > Why does the gradle of geode-jvsd have an internal execution of maven
> > pom ?
> >
> > Better replacing the pom with gradle no ?
> >
> >
> >
> > Dor
> >
> >
> >
> > *From:* Jens Deppe [mailto:jde...@pivotal.io]
> > *Sent:* יום ג 05 אפריל 2016 19:32
> >
> >
> > *To:* u...@geode.incubator.apache.org
> > *Subject:* Re: geode in maven repository
> >
> >
> >
> > Gal,
> >
> >
> >
> > Also, if you're building Geode from source, the 'install' task will
> > create artifacts in your local maven repository.
> >
> >
> >
> > --Jens
> >
> >
> >
> > On Tue, Apr 5, 2016 at 8:49 AM, Gregory Chase <gch...@pivotal.io> wrote:
> >
> > Hi Gal,
> >
> > There's never a specific "time" for a next Apache release. You will
> > see the voting activity in the dev mail list when its time to push a
> release.
> >
> >
> >
> > You can also track status here:
> > https://cwi

Re: MultiAxisChartFX and jvsd

[Jacob Barrett]

A complete rewrite of MultiAxisChartFX is not planned. The MultiAxisChartFX
is derived from the OpenJDK XYChart and carries the same GPL with class
path exception that the JDK does. The plan is to merge jVSD into the
develop branch with the dependency as is. The binary distribution will not
contain the dependency. On first execution of jVSD it will prompt and
download the dependency.

-Jake


On Sun, May 8, 2016 at 8:10 AM Daniel Farcovich 
wrote:

> Hi,
>
> Is jvsd going to be merged to the main branch anytime soon?
>
> Will MultiAxisChartFX class be replaced by another class which complies
> with Apache 2.0 license?
>
>
>
> Thanks,
>
> Daniel
>
>
>
> *From:* Juan José Ramos [mailto:jra...@pivotal.io ]
> *Sent:* יום ד 06 אפריל 2016 10:56
> *To:* u...@geode.incubator.apache.org
> *Subject:* Re: geode in maven repository
>
>
>
> Hey Dor,
>
>
>
> According to Jens (from the mail list history):
>
> *The MultiAxisChartFX class is GPL code and cannot have an Apache 2.0
> license attached to it. This is the reason this code was in a separate
> repo. A*
>
> *user would need to build that separately and then reference it in this
> project."*
>
>
>
> Hope this helps.
>
> Best regards.
>
>
>
>
>
> On Wed, Apr 6, 2016 at 8:36 AM, Dor Ben Dov 
> wrote:
>
> Do you remember which dep’ is preventing it from being Apache license 2 ?
>
> Maybe it’s something –we as community can do ?
>
>
>
> Dor
>
>
>
> *From:* Juan José Ramos [mailto:jra...@pivotal.io]
> *Sent:* יום ד 06 אפריל 2016 10:30
> *To:* u...@geode.incubator.apache.org
> *Subject:* Re: geode in maven repository
>
>
>
> Hi Dor,
>
>
>
> As my understanding, the project MultiAxisChart doesn't use the apache
> license and that's the reason is not even included in the development
> branch, so we shouldn't modify the project and include it as part of Geode.
> In the short term we should get rid of the dependency to that project and
> right now we are only using it as it is.
>
> Cheers.
>
>
>
>
>
> On Tue, Apr 5, 2016 at 6:19 PM, Dor Ben Dov 
> wrote:
>
> Jens,
>
> Why does the gradle of geode-jvsd have an internal execution of maven pom
> ?
>
> Better replacing the pom with gradle no ?
>
>
>
> Dor
>
>
>
> *From:* Jens Deppe [mailto:jde...@pivotal.io]
> *Sent:* יום ג 05 אפריל 2016 19:32
>
>
> *To:* u...@geode.incubator.apache.org
> *Subject:* Re: geode in maven repository
>
>
>
> Gal,
>
>
>
> Also, if you're building Geode from source, the 'install' task will create
> artifacts in your local maven repository.
>
>
>
> --Jens
>
>
>
> On Tue, Apr 5, 2016 at 8:49 AM, Gregory Chase  wrote:
>
> Hi Gal,
>
> There's never a specific "time" for a next Apache release. You will see
> the voting activity in the dev mail list when its time to push a release.
>
>
>
> You can also track status here:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Management
>
>
>
> You should also join our Geode Clubhouse community call tomorrow, 9AM
> Pacific Daylight Time: http://markmail.org/message/2ylydxxlo7zsax6y
>
>
>
> We will likely be discussing the status of the next release towards the
> end.
>
>
>
> On Tue, Apr 5, 2016 at 8:44 AM, Gal Palmery 
> wrote:
>
> Thanks Anthony,
> And when is the next planned release ?
>
>
> -Original Message-
> From: Anthony Baker [mailto:aba...@pivotal.io]
> Sent: Tuesday, April 05, 2016 17:56
> To: u...@geode.incubator.apache.org
> Subject: Re: geode in maven repository
>
> Hi Gal,
>
> Maven Central only contains official releases approved by the PPMC:
> http://search.maven.org/#search%7Cga%7C1%7Cgeode
>
> The nightly development snapshot versions can be found here:
> https://repository.apache.org/content/repositories/snapshots/
>
> For gradle you would use:
>
> repositories {
>   maven { url "
> https://repository.apache.org/content/repositories/snapshots; } }
>
> dependencies {
>   compile 'org.apache.geode:geode-core:1.0.0-incubating.M2-SNAPSHOT'
> }
>
> Anthony
>
> > On Apr 5, 2016, at 1:41 AM, Gal Palmery  wrote:
> >
> > Hi,
> >
> > I noticed that the maven repository isn’t updated with the new geode
> > jars, how often do you update it? and to which repository are you
> uploading the jars?
> >
> > Thanks,
> > Gal
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement, you may
> > review at http://www.amdocs.com/email_disclaimer.asp
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
>
>
>
>
> --
>
> Greg Chase
>
>
>
> Global Head, Big Data Communities
>
> http://www.pivotal.io/big-data
>
>
>
> Pivotal Software
>
> http://www.pivotal.io/
>
>
>
> 650-215-0477
>
> @GregChase
>
> Blog: http://geekmarketing.biz/
>
>
>
>
>
>
>
>
>
> --
>
> Juan José Ramos 

Re: Reminder: include GEODE-xxx jira ticket # in commit message

[Jacob Barrett]

+1

All changes in the repo should have a ticket.

On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer 
wrote:

> My opinion is that no work should be done without a JIRA. That way there
> is a "documentation" on what the task is and you can measure the outcome
> based on the JIRA.
>
> One might think that one could end up in a scenario where we'd end up
> creating JIRA's for the sake of creating JIRA's. But in the long run
> those "trivial" tasks become less frequent.
>
> I also thought that there was some unwritten rule that no changes shall
> be made directly in trunk/develop? ;)
>
>
>
> On 1/03/2016 6:05 am, Dan Smith wrote:
> > My opinion is that docs and minor changes to tests or build scripts don't
> > need necessarily a JIRA. So I'm not sure we want to enforce this with a
> > hook.
> >
> > That said, I definitely see commits in the log that look like product bug
> > fixes, and I totally agree those should have ticket #s in the commit.
> >
> > Jason suggested something that I think might be a good idea - for changes
> > that don't need a JIRA, maybe we can put some other tag in that spot. For
> > example:
> >
> > DOCS: Update most occurrences of "Geode" to "Apache Geode".
> >
> > -Dan
> >
> > On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz <
> kareem.shab...@gmail.com>
> > wrote:
> >
> >> Is it by design that there are no client-side Git hooks to prevent this
> >> sort of thing?
> >>
> >> --
> >> Kareem
> >>
> >>
> >>
> >>
> >> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" 
> >> wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Please remember to include the GEODE-xxx jira ticket # in your commit
> >> messages. I'm looking at git log on develop and I can't correlate
> several
> >> checkins with any jira tickets.
> >>
> >> Thanks,
> >> Kirk
> >>
> >>
> >>
> >>
> >>
> >>
>
>

Re: AvailablePort.getRandomAvailablePort and CI failures

[Jacob Barrett]

+1

I am dealing with the same issue on some tests on the C++ side that do the
same thing. I had planned to fix it the same way that you proposed.

Given that there are lots of ports to configure in Geode maybe as those
ports are activated they should be written to a properties file in the
working directory next to the stats, logs, etc. After the server is started
any script or executable should be able to parse that file to find the
ports it needs.

-Jake




On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund  wrote:

> I'm seeing more and more CI failures caused by our use of
> AvailablePort.getRandomAvailablePort. When the test calls
> AvailablePort.getRandomAvailablePort, a random port is found. But by the
> time the test actually goes to use the port it's already in use.
>
> It doesn't really make sense to fix this one test at a time since we have a
> very large number of tests doing this and hitting this failure in CI.
>
> I believe the correct fix would be to sweep through the tests to get rid of
> our use of AvailablePort.getRandomAvailablePort, use zero for the port and
> then ask the server what port it ended up using if we need the port for
> something.
>
> Trying to determine a randomly available port up front before using it is
> just a race condition waiting to happen.
>
> Thoughts?
>
> Caused by: java.net.BindException: Address already in use
>   at java.net.PlainSocketImpl.socketBind(Native Method)
>   at java.net
> .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
>   at java.net.ServerSocket.bind(ServerSocket.java:375)
>   at
>
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
>   ... 27 more
>
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
>   at
>
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
>   at
>
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
>   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:497)
>   at hydra.MethExecutor.execute(MethExecutor.java:198)
>   at
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
>   at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
>   at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:200)
>   at sun.rmi.transport.Transport$1.run(Transport.java:197)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>   at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>   at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>   at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>   ... 3 more
>

Re: AvailablePort.getRandomAvailablePort and CI failures

[Jacob Barrett]

Yes, both. The native version of Dunit selects ports (some coming from the
driving script too) and passed them to the start scripts. Parallel tests
are tough.

On Tue, Feb 9, 2016 at 4:22 PM Dan Smith <dsm...@pivotal.io> wrote:

> +1
>
> This will also help us if we ever get around to parallelizing the tests.
>
> -Dan
>
> On Tue, Feb 9, 2016 at 2:55 PM, Sai Boorlagadda <sboorlaga...@pivotal.io>
> wrote:
>
> > +1
> >
> > As setting '0' is the fix for most of the tickets that are fixed in JIRA
> > for this exception.
> >
> > Sai
> >
> > On Tue, Feb 9, 2016 at 2:39 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> > > For the C++ client tests, are the ports being used in the Java Server
> and
> > > Locator?
> > >
> > > -Kirk
> > >
> > >
> > > On Tue, Feb 9, 2016 at 2:01 PM, Jacob Barrett <jbarr...@pivotal.io>
> > wrote:
> > >
> > > > +1
> > > >
> > > > I am dealing with the same issue on some tests on the C++ side that
> do
> > > the
> > > > same thing. I had planned to fix it the same way that you proposed.
> > > >
> > > > Given that there are lots of ports to configure in Geode maybe as
> those
> > > > ports are activated they should be written to a properties file in
> the
> > > > working directory next to the stats, logs, etc. After the server is
> > > started
> > > > any script or executable should be able to parse that file to find
> the
> > > > ports it needs.
> > > >
> > > > -Jake
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
> > > >
> > > > > I'm seeing more and more CI failures caused by our use of
> > > > > AvailablePort.getRandomAvailablePort. When the test calls
> > > > > AvailablePort.getRandomAvailablePort, a random port is found. But
> by
> > > the
> > > > > time the test actually goes to use the port it's already in use.
> > > > >
> > > > > It doesn't really make sense to fix this one test at a time since
> we
> > > > have a
> > > > > very large number of tests doing this and hitting this failure in
> CI.
> > > > >
> > > > > I believe the correct fix would be to sweep through the tests to
> get
> > > rid
> > > > of
> > > > > our use of AvailablePort.getRandomAvailablePort, use zero for the
> > port
> > > > and
> > > > > then ask the server what port it ended up using if we need the port
> > for
> > > > > something.
> > > > >
> > > > > Trying to determine a randomly available port up front before using
> > it
> > > is
> > > > > just a race condition waiting to happen.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Caused by: java.net.BindException: Address already in use
> > > > >   at java.net.PlainSocketImpl.socketBind(Native Method)
> > > > >   at java.net
> > > > > .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> > > > >   at java.net.ServerSocket.bind(ServerSocket.java:375)
> > > > >   at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> > > > >   ... 27 more
> > > > >
> > > > >   at junit.framework.Assert.fail(Assert.java:57)
> > > > >   at junit.framework.TestCase.fail(TestCase.java:227)
> > > > >   at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> > > > >   at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> > > > >   at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> > > > >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > >   at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
&

Can we change JIRA notifications?

[Jacob Barrett]

In line with William's request to limit the JIRA emails on feature
branches, can we change the notification model for all JIRAs to something
less frequent.

Only have the initial create notification go to the entire group. After
that only those "watching" the JIRA will get notifications. If you want to
watch a ticket you can open the JIRA and add yourself as a watcher. You are
automatically added if you comment or own the ticket.

-Jake

Re: Deprecating subregions

[Jacob Barrett]

The concept of "deprecating" need to be rethought. Deprecating something
for an entire major release isn't helpful to anyone. The user still expects
it to work. Developers give it no love or attention. Things break. Then the
next release when it is pulled the user has to update their code anyway. It
seems rather pointless to keep something like this around if you know you
won't support it and the next release will drop it any.

-Jake

On Thu, Jan 7, 2016 at 12:03 PM Michael Stolz  wrote:

> Yeah this is actually pretty common, but I think they could get the same
> behavior just by naming the regions appropriately.
>
> Subregions are used by at least a handful of financial services users.
>
> I still think we ought to deprecate them, keep them in for awhile but plan
> to kill them off in a year or so.
>
>

Re: Review Request 41803: GEODE-718: Sanitize passwords in gfsh history file

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41803/#review112592
---

Ship it!


Ship It!

- Jacob Barrett


On Dec. 30, 2015, 10:57 a.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41803/
> ---
> 
> (Updated Dec. 30, 2015, 10:57 a.m.)
> 
> 
> Review request for geode, Anthony Baker and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-718: Sanitize passwords in gfsh history file
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/shell/jline/GfshHistory.java
>  dc3fbe19c89b4650a5a4770f3cd10dada3c04912 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/management/internal/cli/shell/GfshHistoryJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/41803/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: License headers on new source files

[Jacob Barrett]

There are plugins for gradle that check for copyright and license headers. They 
can be configured to fail the build if they are missing from any files. It 
would be a good way to make sure all files have the headers.




-Jake







—

Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Tue, Nov 24, 2015 at 3:05 PM, Anthony Baker <aba...@pivotal.io> wrote:

> Niall points out on GEODE-18 that new files are being added without the 
> appropriate license header.  Please make sure any new files have the ASL 
> header at the top.
> Here’s the snippet to use:
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> Anthony

Re: incubator-geode git commit: GEM-111: Cannot use 8.0.0.9+ clients with 8.1+ servers Added support for version 8009

[Jacob Barrett]

This should have a GEODE ticket created for this work.




—

Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Tue, Nov 10, 2015 at 11:41 AM, Mark Bretl <mbr...@pivotal.io> wrote:

> Hey Barry,
> Is there a reason why this is checked in Geode? It seems this is not Geode
> issue, as it is using a JIRA issue other than GEODE-XXX.
> --Mark
> On Tue, Nov 10, 2015 at 11:19 AM, <bogle...@apache.org> wrote:
>> Repository: incubator-geode
>> Updated Branches:
>>   refs/heads/develop b31336296 -> e1eb74eff
>>
>>
>> GEM-111: Cannot use 8.0.0.9+ clients with 8.1+ servers Added support for
>> version 8009
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/incubator-geode/repo
>> Commit:
>> http://git-wip-us.apache.org/repos/asf/incubator-geode/commit/e1eb74ef
>> Tree: http://git-wip-us.apache.org/repos/asf/incubator-geode/tree/e1eb74ef
>> Diff: http://git-wip-us.apache.org/repos/asf/incubator-geode/diff/e1eb74ef
>>
>> Branch: refs/heads/develop
>> Commit: e1eb74effef800fa67db1c4010ecd67f05ea3b6b
>> Parents: b313362
>> Author: Barry Oglesby <bogle...@pivotal.io>
>> Authored: Mon Nov 2 17:42:43 2015 -0800
>> Committer: Barry Oglesby <bogle...@pivotal.io>
>> Committed: Tue Nov 10 10:26:06 2015 -0800
>>
>> --
>>  .../src/main/java/com/gemstone/gemfire/internal/Version.java| 5 +
>>  .../gemfire/internal/cache/tier/sockets/CommandInitializer.java | 4 
>>  .../internal/cache/tier/sockets/command/ExecuteFunction66.java  | 2 +-
>>  .../cache/tier/sockets/command/ExecuteRegionFunction66.java | 2 +-
>>  .../tier/sockets/command/ExecuteRegionFunctionSingleHop.java| 2 +-
>>  5 files changed, 12 insertions(+), 3 deletions(-)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/e1eb74ef/gemfire-core/src/main/java/com/gemstone/gemfire/internal/Version.java
>> --
>> diff --git
>> a/gemfire-core/src/main/java/com/gemstone/gemfire/internal/Version.java
>> b/gemfire-core/src/main/java/com/gemstone/gemfire/internal/Version.java
>> index 936ae79..8726ba8 100644
>> --- a/gemfire-core/src/main/java/com/gemstone/gemfire/internal/Version.java
>> +++ b/gemfire-core/src/main/java/com/gemstone/gemfire/internal/Version.java
>> @@ -175,6 +175,11 @@ public final class Version implements
>> Comparable {
>>
>>// 31-34 available for 8.0.x variants
>>
>> +  private static final byte GFE_8009_ORDINAL = 31;
>> +
>> +  public static final Version GFE_8009 = new Version("GFE", "8.0.0.9",
>> (byte)8,
>> +  (byte)0, (byte)0, (byte)9, GFE_8009_ORDINAL);
>> +
>>private static final byte GFE_81_ORDINAL = 35;
>>
>>public static final Version GFE_81 = new Version("GFE", "8.1", (byte)8,
>>
>>
>> http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/e1eb74ef/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CommandInitializer.java
>> --
>> diff --git
>> a/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CommandInitializer.java
>> b/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CommandInitializer.java
>> index 7e49d7a..26ed47b 100755
>> ---
>> a/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CommandInitializer.java
>> +++
>> b/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CommandInitializer.java
>> @@ -301,6 +301,10 @@ public class CommandInitializer {
>>  gfe80Commands.put(MessageType.PUTALL, PutAll80.getCommand());
>>  ALL_COMMANDS.put(Version.GFE_80, gfe80Commands);
>>
>> +Map<Integer, Command> gfe8009Commands = new HashMap<Integer,
>> Command>();
>> +gfe8009Commands.putAll(ALL_COMMANDS.get(Version.GFE_80));
>> +ALL_COMMANDS.put(Version.GFE_8009, gfe8009Commands);
>> +
>>  {
>>Map<Integer, Command> gfe81Commands = new HashMap<Integer,
>> Command>();
>>gfe81Commands.putAll(ALL_COMMANDS.get(Version.GFE_80));
>>
>>
>> http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/e1eb74ef/gemfire-core

Re: Review Request 39278: GEODE-396: Fix server to use server/gateway ssl config

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39278/#review102494
---

Ship it!


Ship It!

- Jacob Barrett


On Oct. 13, 2015, 9:44 a.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39278/
> ---
> 
> (Updated Oct. 13, 2015, 9:44 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jacob Barrett.
> 
> 
> Bugs: GEODE-396
> https://issues.apache.org/jira/browse/GEODE-396
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The AcceptorImpl now keeps the non-default SocketCreator it makes
> with the server/gateway ssl and uses it for all connections
> from the client instead of the default cluster ssl config.
> 
> The extra logging done by the server that included the keystore
> and truststore passwords (in clear text) has been removed.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/AcceptorImpl.java
>  74cdfa979a027f6f3ffac56bfc4096a93497450a 
> 
> Diff: https://reviews.apache.org/r/39278/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Re: Review Request 39195: GEODE-331 Bump Jetty version to 9.2.13.v20150730

[Jacob Barrett]

I think we had a discussion about dropping 1.7 support in geode.

On Fri, Oct 9, 2015 at 4:32 PM, Jens Deppe  wrote:

>> On Oct. 9, 2015, 11:11 p.m., William Markito wrote:
>> > Hi Jens! Why not go to 9.3 ?
> 9.3 is JDK8 only
> - Jens
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39195/#review102132
> ---
> On Oct. 9, 2015, 11:07 p.m., Jens Deppe wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/39195/
>> ---
>> 
>> (Updated Oct. 9, 2015, 11:07 p.m.)
>> 
>> 
>> Review request for geode and Mark Bretl.
>> 
>> 
>> Repository: geode
>> 
>> 
>> Description
>> ---
>> 
>> - this addresses CVE-2015-2080
>> 
>> 
>> Diffs
>> -
>> 
>>   gemfire-core/build.gradle 1c1747447b082130a1c5860f52acac28e1a5b28d 
>> 
>> Diff: https://reviews.apache.org/r/39195/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> Check versions in dpendency-only jars
>> 
>> Manual launch of Pulse and REST API
>> 
>> 
>> Thanks,
>> 
>> Jens Deppe
>> 
>>

Re: Review Request 39110: Adding xml parsing and generation logic

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39110/#review101931
---



gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlGenerator.java
 (lines 35 - 37)
<https://reviews.apache.org/r/39110/#comment159435>

Consider using additional elements rather than a unstructured list like 
this.


  
  


This is "better" XML and allows for future expansion.




gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneXmlParser.java
 (line 36)
<https://reviews.apache.org/r/39110/#comment159436>

See comment on breaking fields into collection of field elements.



gemfire-lucene/src/main/resources/META-INF/schemas/geode.incubator.apache.org/lucene/lucene-1.0.xsd
 (lines 3 - 4)
<https://reviews.apache.org/r/39110/#comment159438>

Will you be able to host the schema at this location?



gemfire-lucene/src/main/resources/META-INF/schemas/geode.incubator.apache.org/lucene/lucene-1.0.xsd
 (line 25)
<https://reviews.apache.org/r/39110/#comment159439>

Will you be able to host the schema at this location?



gemfire-lucene/src/main/resources/META-INF/schemas/geode.incubator.apache.org/lucene/lucene-1.0.xsd
 (line 33)
<https://reviews.apache.org/r/39110/#comment159437>

See comment on breaking fields into collection of field elements.


- Jacob Barrett


On Oct. 7, 2015, 4:34 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39110/
> ---
> 
> (Updated Oct. 7, 2015, 4:34 p.m.)
> 
> 
> Review request for geode, Ashvin A and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We now have an xsd for the lucene elements, and a LuceneXmlParser
> service. Geode already has a mechanism to plug in additional xml parsers
> like LuceneXmlParsers by using the java service loader, which I have
> done.
> 
> I've written a LuceneIndexCreation object to match other configuration
> objects that get generated when a cache is parsed. This creation is
> attached to regions on index creation time so that when xml is
> generated, the creation object and generate the appropriate xml snippet.
> 
> 
> Diffs
> -
> 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  60085e45346cdda7e473daf505760eb47a6f7cb8 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
>  c2d2ce25d2e46a67edd2e55b85349010374f9a53 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImpl.java
>  2c4db9d3ad68111acbddbe6b279c1d3a05f2747a 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexCreation.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlGenerator.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneServiceXmlGenerator.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneXmlConstants.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneXmlParser.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/resources/META-INF/schemas/geode.incubator.apache.org/lucene/lucene-1.0.xsd
>  PRE-CREATION 
>   
> gemfire-lucene/src/main/resources/META-INF/services/com.gemstone.gemfire.internal.cache.xmlcache.XmlParser
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlGeneratorIntegrationJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlGeneratorJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlParserIntegrationJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlParserJUnitTest.java
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/resources/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlParserIntegrationJUnitTest.createIndex.cache.xml
>  PRE-CREATION 
>   
> gemfire-lucene/src/test/resources/com/gemstone/gemfire/cache/lucene/internal/xml/LuceneIndexXmlParserIntegrationJUnitTest.parseIndex.cache.xml
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/39110/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 39107: Adding an EntityResolver for the apache namespace

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39107/#review101932
---

Ship it!



gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/DefaultEntityResolver2.java
 (line 53)
<https://reviews.apache.org/r/39107/#comment159440>

DOH! Thanks!


Looks great!

- Jacob Barrett


On Oct. 7, 2015, 4:17 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39107/
> ---
> 
> (Updated Oct. 7, 2015, 4:17 p.m.)
> 
> 
> Review request for geode, Ashvin A, Jacob Barrett, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This will look for xsd files and other xml entities on the classpath if
> they are in the http://geode.incubator.apache.org/schema namespace.
> 
> Also, correcting a misspelling in getClassPathInputSource.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/DefaultEntityResolver2.java
>  7e7135f0800c8be6c0a310caa0c832dfcd26f6b0 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/GeodeEntityResolver.java
>  PRE-CREATION 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/PivotalEntityResolver.java
>  27e276480cdb154765ca66995c2e598ccb76e3b8 
>   
> gemfire-core/src/main/resources/META-INF/services/org.xml.sax.ext.EntityResolver2
>  5901ec144ed578f9e22882f4c0c8d75638b0cae7 
> 
> Diff: https://reviews.apache.org/r/39107/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: xml schema locations

[Jacob Barrett]

Does the ASF have a central schema respository we can use?



Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Thu, Oct 8, 2015 at 11:41 AM, William Markito <wmark...@pivotal.io>
wrote:

> I'm concerned that we will need another update on applications and other
> usages and after TLP, since we'll drop the .incubator of the url.
> But I don't have a better alternative yet to propose.
> On Thu, Oct 8, 2015 at 11:23 AM, Dan Smith <dsm...@pivotal.io> wrote:
>> I filed a JIRA for changing the xml schema location from pivotal to apache,
>> see GEODE-386.
>>
>> I'm proposing hosting the schemas at
>>
>> http://geode.incubator.apache.org/schema/cache
>>
>> For example:
>> http://geode.incubator.apache.org/schema/cache/cache-1.0.xsd
>>
>> Does this meet with everyone's approval? Will there be an issues with
>> putting schemas in this location on the website?
>>
>> -Dan
>>
> -- 
> William Markito Oliveira
> Enterprise Architect
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> <dev@geode.incubator.apache.org>*

Re: GEODE-327: Rename gemfire-junit to gemfire-common

[Jacob Barrett]

+1




Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Sat, Sep 12, 2015 at 11:16 AM, Kirk Lund <kirk.l...@gmail.com> wrote:

> I'm pretty sure we could rename gemfire-junit to gemfire-test.
> gemfire-junit was named only because of gemfire-test existing in a
> different repo.
> Currently, all of our reusable testing utilities/classes/rules are under
> src/test/java in either gemfire-junit or gemfire-core (dunit is all under
> the latter because it depends on DistributedSystem). This placement is a
> hold-over from the old build structure.
> I think creating a library of test common is a good idea and the testing
> classes would probably move from src/test/java into src/main/java and then
> be assembled into a jar (such as gemfire-test-common.jar). Is that the
> general idea?
> All of our dependencies on gemfire-junit are currently other subprojects
> depending on its build dir which contains the classes from its
> src/test/java (hence no jar).
> gemfire-common (reusable non-test-related components)
> gemfire-test (reusable test-related components)
> gemfire-core currently has more reusable test-related components than
> gemfire-junit, but all of these (including Annotations, custom Rules, etc)
> are currently under src/test/java as well. If we're going to clean up
> gemfire-junit(test) and move its classes from src/test/java (except the
> tests) to src/main/java then we should do the same for dunit and other
> reusable test-related components in gemfire-core as well.
> -Kirk
> On Sat, Sep 12, 2015 at 10:34 AM, Jacob Barrett <jbarr...@pivotal.io> wrote:
>> You don't want runtime libraries and test time libraries in the same jar.
>> Putting junit utility and annotation classes that would only be used in
>> junits in a jar that would have to be included in a production class path
>> is broken. Gemfire-common.jar would imply something common to gemfire at
>> runtime, like string utils, logging, and other cross cutting runtime
>> concerns.
>>
>>
>>
>>
>> If you want a library for common test classes then think
>> gemfire-test-common.jar or something.
>>
>>
>>
>>
>> Jacob Barrett
>> Manager
>> GemFire Advanced Customer Engineering (ACE)
>> Pivotal
>>
>> jbarr...@pivotal.io
>> 503-533-3763
>>
>> For immediate support please contact Pivotal Support at
>> http://support.pivotal.io/
>>
>> On Sat, Sep 12, 2015 at 7:04 AM, Anthony Baker <aba...@pivotal.io> wrote:
>>
>> > Annotations are utilities…?  The gemfire-junit name seems unnecessarily
>> restrictive.  Currently it only contains annotations related to junit tests.
>> > Hadoop defines both hadoop-annotations and hadoop-common.
>> > Anthony
>> >> On Sep 11, 2015, at 9:08 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
>> >>
>> >> -1
>> >>
>> >>
>> >>
>> >>
>> >> Reserve common for things common to geode development not related to
>> unit testing. Like utilities classes.
>> >>
>> >>
>> >>
>> >>
>> >> Jacob Barrett
>> >> Manager
>> >> GemFire Advanced Customer Engineering (ACE)
>> >> Pivotal
>> >>
>> >> jbarr...@pivotal.io
>> >> 503-533-3763
>> >>
>> >> For immediate support please contact Pivotal Support at
>> http://support.pivotal.io/
>> >>
>> >> On Fri, Sep 11, 2015 at 12:04 PM, Kirk Lund <kirk.l...@gmail.com>
>> wrote:
>> >>
>> >>> I filed ticket GEODE-327 to propose renaming gemfire-junit to
>> >>> gemfire-common.
>> >>> We'd like to be able to define common annotations in this
>> gemfire-common
>> >>> and not be limited to code that is specific to junit or testing. The
>> first
>> >>> annotation would be Experimental (see GEODE-328).
>> >>> Please vote on making this change.
>> >>> Thanks,
>> >>> Kirk
>>

Re: GEODE-327: Rename gemfire-junit to gemfire-common

[Jacob Barrett]

You don't want runtime libraries and test time libraries in the same jar. 
Putting junit utility and annotation classes that would only be used in junits 
in a jar that would have to be included in a production class path is broken. 
Gemfire-common.jar would imply something common to gemfire at runtime, like 
string utils, logging, and other cross cutting runtime concerns.




If you want a library for common test classes then think 
gemfire-test-common.jar or something.




Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Sat, Sep 12, 2015 at 7:04 AM, Anthony Baker <aba...@pivotal.io> wrote:

> Annotations are utilities…?  The gemfire-junit name seems unnecessarily 
> restrictive.  Currently it only contains annotations related to junit tests.
> Hadoop defines both hadoop-annotations and hadoop-common.
> Anthony
>> On Sep 11, 2015, at 9:08 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
>> 
>> -1
>> 
>> 
>> 
>> 
>> Reserve common for things common to geode development not related to unit 
>> testing. Like utilities classes.
>> 
>> 
>> 
>> 
>> Jacob Barrett 
>> Manager 
>> GemFire Advanced Customer Engineering (ACE) 
>> Pivotal
>> 
>> jbarr...@pivotal.io 
>> 503-533-3763
>> 
>> For immediate support please contact Pivotal Support at 
>> http://support.pivotal.io/
>> 
>> On Fri, Sep 11, 2015 at 12:04 PM, Kirk Lund <kirk.l...@gmail.com> wrote:
>> 
>>> I filed ticket GEODE-327 to propose renaming gemfire-junit to
>>> gemfire-common.
>>> We'd like to be able to define common annotations in this gemfire-common
>>> and not be limited to code that is specific to junit or testing. The first
>>> annotation would be Experimental (see GEODE-328).
>>> Please vote on making this change.
>>> Thanks,
>>> Kirk

Re: GEODE-218: Dunit Fork Every 1

[Jacob Barrett]

Can any of them be launched in parallel? This could cut down time significantly.




Jacob Barrett 
Manager 
GemFire Advanced Customer Engineering (ACE) 
Pivotal

jbarr...@pivotal.io 
503-533-3763

For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Fri, Sep 4, 2015 at 11:17 AM, Mark Bretl <mbr...@pivotal.io> wrote:

> I see that Kirk made an update to the issue and wanted to follow up on the
> Dev list for discussion.
> I also ran a build on the open side with the dunit fork = 1. The total time
> of the build was: 9 hrs 58 mins 33.662 secs. The last Geode build took: 6
> hr 21 min <https://builds.apache.org/job/Geode-nightly/buildTimeTrend>.
> It is an increase of about 3.5 hours, which matches the increase in time
> that Kirk had.
> The question becomes: Do we want to make the change so we can increase the
> quality of tests by isolating each one at the cost of increasing the total
> build time?
> My thoughts would be to make the change to weed out the 'bad' tests and
> increase the overall quality of the tests, so when a test fails there is no
> questioning the result. Once we have them passing more consistently, then
> we can increase the fork count again.
> Thoughts?
> -- 
> Mark Bretl
> Software Build Engineer
> Pivotal
> 503-533-3869
> www.pivotal.io

Re: Review Request 37702: GEODE-264: Fix varargs compiler warnings

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37702/#review96120
---


You can leave off the vararg argument completely as well. The null will be 
implied.
```java
method.invoke(null);
```
is the same as
```java
method.invoke(null, (Object[]) null);
```
but in my opinion a little more readable.

- Jacob Barrett


On Aug. 22, 2015, 9:03 a.m., Anthony Baker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/37702/
 ---
 
 (Updated Aug. 22, 2015, 9:03 a.m.)
 
 
 Review request for geode and Kirk Lund.
 
 
 Repository: geode
 
 
 Description
 ---
 
 Add casts where needed so that invoke(null, null) is now
 invoke(null, (Ojbect[]) null).
 
 
 Diffs
 -
 
   
 gemfire-core/src/test/java/com/gemstone/gemfire/internal/compression/SnappyCompressorJUnitTest.java
  56d647af99178bdb71f6969277cfe3c3f6769ea9 
   gemfire-core/src/test/java/dunit/standalone/DUnitLauncher.java 
 0f2eebcfc4e17501038f4e5300ea653ebc904b4d 
 
 Diff: https://reviews.apache.org/r/37702/diff/
 
 
 Testing
 ---
 
 Ran SnappyCompressorJUnitTest and a DUnit test.
 
 
 Thanks,
 
 Anthony Baker
 

Re: YCSB driver for Geode

[Jacob Barrett]

Do you have a corresponding error message or indicator of it not being 
compatible?





—

Jacob Barrett

Manager

GemFire Advanced Customer Engineering (ACE)

Pivotal




jbarr...@pivotal.io

503-533-3763




For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Thu, Aug 13, 2015 at 12:58 PM, Roman Shaposhnik r...@apache.org wrote:

 Hi!
 it seems that the gemfire's cache.xml is no
 longer compatible with Geode. Can someone
 please help me come up with the update
 that makes sense? The following seems to
 work, but I'm not sure how optimal it is:
 client-cache
   pool name=client subscription-enabled=true
   locator host=10.0.2.15 port=10334/
   /pool
   region name=usertable
  region-attributes pool-name=client refid=CACHING_PROXY/
   /region
 /client-cache
 Thanks,
 Roman.

Re: Review Request 37209: GEODE-17 : Integrated Security Code Merge

[Jacob Barrett]

Performance vs. security should never be considered. Security trumps everything.


We should adopt standards where available. We should use other open source 
libraries where applicable. As part of the Apache ecosystem now we need to look 
at Apache projects that may provide these capabilities. We rarely want to 
reinvent something, especially in security.




-Jake


—

Jacob Barrett

Manager

GemFire Advanced Customer Engineering (ACE)

Pivotal




jbarr...@pivotal.io

503-533-3763




For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Fri, Aug 7, 2015 at 9:28 AM, Anthony Baker aba...@pivotal.io wrote:

 Am I missing something?  Not verifying the integrity of a security token 
 creates a vulnerability, right?
 Have you quantified the performance impact of Spring Security?
 Anthony
 
 Agreed. Initially I had spec'd it out based on Spring Security. But 
 Neelkanth felt token based approach is better for performance where we check 
 only for presence of Token but not its Integrity
 
 
 - Tushar
 

Re: Nabble for Geode mail archives?

[Jacob Barrett]

That brings up a good question. Why is the ASF infrastructure so behind in mail 
list technology? Mod_mbox has got to be the most dated web service I have seen 
in a long time. No searching, threads index doesn’t span months, and don’t 
forget the 1995 web styling. ;)




Can we not have our website direct people to something more useful?


—

Jacob Barrett

Manager

GemFire Advanced Customer Engineering (ACE)

Pivotal




jbarr...@pivotal.io

503-533-3763




For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Thu, Aug 6, 2015 at 4:04 PM, William Markito wmark...@pivotal.io
wrote:

 I've been using this for search on our archive
 http://geode.markmail.org/search/?q=
 On Thu, Aug 6, 2015 at 4:00 PM, Gregory Chase gch...@pivotal.io wrote:
 In the early days, I saw some other communities using Nabble for achives,
 so I set this up:
 http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

 If anyone likes it and wants to save it, feel free to hit the don't delete
  button at the top.

 However, officially, we're pointing to the ASF archive infrastructure.


 --
 Greg Chase

 Director of Big Data Communities
 http://www.pivotal.io/big-data

 Pivotal Software
 http://www.pivotal.io/

 650-215-0477
 @GregChase
 Blog: http://geekmarketing.biz/

 -- 
 William Markito Oliveira
 Enterprise Architect
 -- For questions about Apache Geode, please write to
 *dev@geode.incubator.apache.org
 dev@geode.incubator.apache.org*

Re: Review Request 36906: GEODE-150 Implemented merge function for Aggregator interface. Made the aggregators DataSerializable

[Jacob Barrett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36906/#review93616
---


The only comment I have on the XSD change is to potentially look at an 
exisisting complex type for your UDA type. Perhaps have uda extend 
class-with=parameters-type and add just add an attribute name if name is 
really necessary. If gaining the parameters helps in anyway I would highly 
recommend it. Here is what it would look like.

xsd:element maxOccurs=unbounded minOccurs=0 name=uda
  xsd:complexType
xsd:complexContent
  xsd:extension base=gf:class-with-parameters-type
xsd:attribute name=name type=xsd:string /
  /xsd:extension
/xsd:complexContent
  /xsd:complexType
/xsd:element

...

xsd:complexType name=class-with-parameters-type
  xsd:sequence
xsd:element name=class-name type=gf:class-name-type /
xsd:element maxOccurs=unbounded minOccurs=0 name=parameter 
type=gf:parameter-type /
  /xsd:sequence
/xsd:complexType


As XML:

uda name=foo
  class-namecom.example.foo.Foo/class-name
  parameter name=p1stringsome string/string/parameter
  parameter 
name=p2declarableclass-namecom.example.foo.SomeOtherClass/class-name/declarable/parameter
/uda

- Jacob Barrett


On July 29, 2015, 2:17 a.m., Asif Shahid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36906/
 ---
 
 (Updated July 29, 2015, 2:17 a.m.)
 
 
 Review request for geode.
 
 
 Repository: geode
 
 
 Description
 ---
 
 Support for UserDefinedAggregates in OQL. Support for allowing creation of 
 UDAs to be used in OQL
 
 
 Implemented changes for uda creation through cache xml ( declarative syntax)
 
 
 Fixed the bug in profile exchange of UDA. Added test for the same
 
 
 Diffs
 -
 
   gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/Aggregator.java 
 9f54eba48072466b139151173216238bc180d289 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/QueryService.java 
 4a3cb46f4de4f263e8a7c8f26684392346f42e4a 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/UDAExistsException.java
  PRE-CREATION 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledAggregateFunction.java
  ba7731026f096cb0bd70d0cc04b391f46492f33a 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledGroupBySelect.java
  ad41c309a906267c3383a4d444a62ad83dbd7ca6 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledUDAFunction.java
  PRE-CREATION 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/DefaultQueryService.java
  71d2e86095e51ead86b24c098dbc8db6de8ffa84 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/ProxyQueryService.java
  8a20f10347aee8f3e29b953b5f39baa49dda017a 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/QCompiler.java
  4777dc1b9a3b7576180fec5e4dc159ed2b30d882 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/AbstractAggregator.java
  5809df8fe85d691807809898f1753b665f355cc1 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/Avg.java
  e1da36d2f57a96829f7f1dc9a71e4ac607d34777 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/AvgBucketNode.java
  96113218cc04c4a98610a1183680fb0da9918c4d 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/AvgDistinct.java
  3863b72a2df3b2e7f27727e409aafcbdae31aa4e 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/AvgDistinctPRQueryNode.java
  2bbc67d2a4b44c60da9882bd95e7b7c289c8fc20 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/AvgPRQueryNode.java
  23654742130dbb1d20f3fb2e45c29eb0dbea46db 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/Count.java
  3026b63e5a3a8f6a3bf1b4553b8e611a111dbd7a 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/CountDistinct.java
  03af70bf6cee6ce0fd37227efbd33b5419a0e6f3 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/CountDistinctPRQueryNode.java
  4e56f303d227ba2f746b8d86b56134c3c3182182 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/CountPRQueryNode.java
  34d34ac17b16bd9b9eb2ca06f022099b798ae191 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/aggregate/DistinctAggregator.java
  0328d9a4c06a832daf9ca2aabcb2ec8bb22403e4 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/query

Re: Review Request 36397: HdfsStore API refactoring

[Jacob Barrett]

+1




We need to fail reviews that don’t have unit tests. There is a handy field on 
the review board for “Testing Done” which should probably used to call out the 
unit tests for the reviewer to run.




-Jake





—

Jacob Barrett

Manager

GemFire Advanced Customer Engineering (ACE)

Pivotal




jbarr...@pivotal.io

503-533-3763




For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Mon, Jul 13, 2015 at 10:27 AM, Kirk Lund kirk.l...@gmail.com wrote:

 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36397/#review91485
 ---
 We really need to start requiring a UnitTests for every change, bugfix, and 
 new code. Can you please think about ways to write UnitTests for this code? 
 What I mean by this is a JUnit UnitTest that probably uses Mockito or JMock 
 and executes in less than 1/10th second. If the code can only be tested by 
 end-to-end tests then we need to break dependencies on outside Collaborators 
 (so they can be passed in as mocked objects) to enable isolating a single 
 class for testing purposes.
 - Kirk Lund
 On July 10, 2015, 8:45 p.m., Ashvin A wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36397/
 ---
 
 (Updated July 10, 2015, 8:45 p.m.)
 
 
 Review request for geode, Amogh Shetkar and Dan Smith.
 
 
 Bugs: GEODE-10
 https://issues.apache.org/jira/browse/GEODE-10
 
 
 Repository: geode
 
 
 Description
 ---
 
 GEODE-10: Refactor HdfsStore api to match spec
 
 * Currently HdfsStore's configuration object is nested and a user needs 
 to
   create multiple sub objects to manage the store instance. This is less 
 usable
   and gets confusing at times. User also gets exposed to a lot of 
 internal
   details. So replacing nested configuration with a flat structure will 
 be
   better.
 * Rename members
 
 
 Diffs
 -
 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSEventQueueAttributes.java
  ef7e863 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSEventQueueAttributesFactory.java
  fc09b7a 
   gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStore.java 
 f5bd943 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStoreFactory.java
  516d2aa 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStoreMutator.java
  47b1708 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSEventQueueAttributesImpl.java
  df89841 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSIntegrationUtil.java
  242923b 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreConfigHolder.java
  50ea3c6 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreCreation.java
  b5fbfe8 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreFactoryImpl.java
  e7e75dc 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreImpl.java
  8e7e358 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreMutatorImpl.java
  e4e2093 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/SizeTieredHdfsCompactionConfigHolder.java
  57d58b7 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/hoplog/HDFSCompactionManager.java
  d96cd11 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/hoplog/HDFSUnsortedHoplogOrganizer.java
  c9be401 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/hoplog/HdfsSortedOplogOrganizer.java
  7bb025b 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
  76488dd 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheCreation.java
  a5fd3f1 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlParser.java
  e015624 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/HDFSStoreCommands.java
  b044156 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/AlterHDFSStoreFunction.java
  13ba5fa 
   
 gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/CreateHDFSStoreFunction.java
  ac9c895 
   
 gemfire-core/src/test/java/com/gemstone/gemfire/cache/hdfs/internal/ColocatedRegionWithHDFSDUnitTest.java
  ea9dc11 
   
 gemfire-core/src/test/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSConfigJUnitTest.java
  dc3f404 
   
 gemfire-core/src/test/java/com/gemstone/gemfire/cache/hdfs/internal/HdfsStoreMutatorJUnitTest.java
  f12078e 
   
 gemfire-core/src/test/java/com

Re: [jira] [Commented] (GEODE-52) Remove @author tags from Java source

[Jacob Barrett]

+1



—

Jacob Barrett

Manager

GemFire Advanced Customer Engineering (ACE)

Pivotal




jbarr...@pivotal.io

503-533-3763




For immediate support please contact Pivotal Support at 
http://support.pivotal.io/

On Fri, Jun 5, 2015 at 3:57 PM, John Blum (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/GEODE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575383#comment-14575383
  ] 
 John Blum commented on GEODE-52:
 
 I don't necessarily agree with this bug.
 IMO... {{@author}} tags are not the same thing as if there were an {{@owner}} 
 tag.  
 In addition, I think the Copyright at the top of the source file is more of 
 an indication to whom the source belongs (i.e. with an ALv2, the 
 community), where as the {{@author}} indicates who authored the source, 
 who might be able to be contacted in case of questions, etc.
 It is also entirely possible a particular source file could have multiple 
 authors, 1 {{@author}} tag for the initial developer and subsequent 
 {{@author}} tags for additional engineers who have modified and maintain the 
 file, leaving a sort of footprint, or stamp on the file to indicate who 
 is familiar with the code.
 For example...
 {code:java}
 /*
  * Copyright 2010-2015 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
  *
  *  http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an AS IS BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 package org.apache.x.y.z;
 import ...
 /**
  * The SomeAplicationComponent class... blah blah blah...
  * 
  * @author jondoe
  * @author agentsmith
  * @see ...
  * @since 1.0.0
  * ...
  */
 public class SomeApplicationComponent ... {
 ...
 }
 {code}
 Here, the Copyright implies to me who owns the rights to the code where as 
 the authors are the ones responsible for creating it, maintaining it, etc.
 Just an opinion as I find the {{@author}} tags useful in certain cases.
 Remove @author tags from Java source
 

 Key: GEODE-52
 URL: https://issues.apache.org/jira/browse/GEODE-52
 Project: Geode
  Issue Type: Bug
Reporter: Jakob Homan

 Apache generally frowns on @author tags (as they imply ownership of the code 
 by a single individual, see 
 https://blogs.oracle.com/ahe/entry/coding_conventions_and_attribution [best 
 asf link is not working, annoyingly] and 
 https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute as an 
 example)
 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)