Geode listed on the top 10 most active mailing lists @ Apache in 2017

[William Markito Oliveira]

Congrats everyone, Happy new year! 

https://blogs.apache.org/foundation/entry/apache-in-2017-by-the

Re: Geode Jira/GitHub Integration configuration changes

[William Markito Oliveira]

+1 for removing the diff - Link to the PR should be good enough.

On Mon, Dec 18, 2017 at 1:18 PM, Jacob Barrett  wrote:

> +1 for reducing noise!
>
> On Mon, Dec 18, 2017 at 10:03 AM Joey McAllister 
> wrote:
>
> > (Er, from JIRA ticket comments, that is.)
> >
> > On Mon, Dec 18, 2017 at 10:02 AM Joey McAllister  >
> > wrote:
> >
> > > +1 to removing the diffs from JIRA tickets.
> > >
> > > On Mon, Dec 18, 2017 at 9:58 AM Dan Smith  wrote:
> > >
> > >> Hi Kirk,
> > >>
> > >> I think this is will probably require a request to infra. You can
> file a
> > >> JIRA with infra assuming we have consensus to get rid of the diffs
> (huge
> > >> +1
> > >> from me:)
> > >>
> > >> Also, please don't cross post with private@geode. The private list
> > should
> > >> *only* be used for things that can't be discussed publicly.
> > >>
> > >> -Dan
> > >>
> > >> https://www.apache.org/dev/infra-contact
> > >>
> > >> On Mon, Dec 18, 2017 at 9:43 AM, Kirk Lund  wrote:
> > >>
> > >> > Since we switched to GitBox for Geode, all Pull Requests are
> resulting
> > >> in
> > >> > huge diffs being posted to the comments on Geode Jira tickets. Some
> of
> > >> > these are resulting in hangs trying to open certain Jira tickets.
> I'd
> > >> like
> > >> > to determine what our options are for changing how this is
> configured.
> > >> >
> > >> > I looked through all of the options in the administration screens
> for
> > >> > Geode Jira but couldn't find anything other than a link to INFRA
> > GitHub
> > >> > Integration that I don't have permission to access (
> > >> >
> > >>
> > https://issues.apache.org/jira/plugins/servlet/project-
> config/GEODE/fields
> > >> > -- search down for "GitHub Integration").
> > >> >
> > >> > Does anyone know where to change this configuration or is this a
> > request
> > >> > that needs to go to ASF INFRA?
> > >> >
> > >> > Thanks,
> > >> > Kirk
> > >> >
> > >>
> > >
> >
>

Re: New client protocol configuration

[William Markito Oliveira]

I was doing something similar to that for some other projects and found
that cfg4j [1] to be a very clean and good framework to keep the format of
the configuration generic and dynamic.  Built-in support for Yaml and
property files and can also ready from multiple sources like Git, Consul,
classpath or filesystem obviously, including merge of configuration files.

We actually started with Apache Commons [2] but decided to go cfg4j because
the API was a bit more clean, but both of them simplified a lot our
configuration efforts.

Just my 0.02c

[1] cfg4j.org/releases/latest/#tutorial
[2] https://commons.apache.org/proper/commons-configuration/

On Thu, Oct 5, 2017 at 3:34 PM, Mark Hanson  wrote:

> One thing also to consider if you modifying the config structure, is an
> evented config structure, so that registrants get callbacks if changes are
> made that are real-time.
>
> Thanks,
> Mark
> > On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan 
> wrote:
> >
> > I don't care too much about exactly what the configuration looks like,
> but
> > I want it to be unified, and I want it to be set when the cache starts.
> > Checking system properties throughout the codebase whenever we feel like
> is
> > a bit too magic for me.
> >
> > In addition, it seems that in order to add a new value to
> > DistributionConfig, I have to add it in several places. Config should be
> in
> > one place. Descriptions, values, ranges should be defined in one place
> and
> > Ideally it should be extendable, and it should have some checks to make
> it
> > hard to shoot yourself in the foot.
> >
> > For this particular problem, it turns out that we should not make it
> > configurable via a property, but should get this information from
> > SecurityService. I think that a unified config solution is something we
> > should look into for the future, though.
> >
> > -Galen
>
>


-- 
~/William

Re: New Geode PMC Member: Galen O'Sullivan

[William Markito Oliveira]

Here is the list. :)

https://projects.apache.org/committee.html?geode


Sent from my iPhone

> On Sep 27, 2017, at 11:33 AM, Swapnil Bawaskar  wrote:
> 
> We have a list of committers here: http://geode.apache.org/community/ but
> we don't have a list of PMC on the geode site.
> Mark, do you maintain one?
> 
>> On Wed, Sep 27, 2017 at 6:09 AM Michael Stolz  wrote:
>> 
>> Where can I see the list of PMC members?
>> 
>> --
>> Mike Stolz
>> Principal Engineer - Gemfire Product Manager
>> Mobile: 631-835-4771 <(631)%20835-4771>
>> 
>>> On Sep 26, 2017 7:49 PM, "Mark Bretl"  wrote:
>>> 
>>> The Apache Geode Project Management Committee has invited Galen
>>> O'Sullivan to join the Geode PMC and we are pleased to announce he has
>>> accepted.
>>> 
>>> Please join me in welcoming Galen!
>>> 
>>> Best regards,
>>> 
>>> Mark
>>> On behalf of the Apache Geode PMC
>>> 
>> 

Re: [VOTE] Apache Geode release - v1.2.1 RC4

[William Markito Oliveira]

+1

Checked:
- Basic operations from command line
- Checksums match
- Release build green (blue actually)  (
https://builds.apache.org/job/Geode-release/lastBuild/)



On Mon, Sep 18, 2017 at 3:57 PM, Dan Smith  wrote:

> +1
>
> The jenkins release build was green and release check passed as well -
> https://github.com/upthewaterspout/geode-release-check
>
> -Dan
>
> On Sat, Sep 16, 2017 at 8:01 AM, Anthony Baker  wrote:
>
> > This is the fourth release candidate for Apache Geode, version 1.2.1.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > *** Please download, test and vote by Wednesday, September 20, 0800 hrs
> > US Pacific. ***
> >
> > It fixes the following issues:
> >  https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12318420=12341124
> >
> > Note that we are voting upon the source tags:  rel/v1.2.1.RC4
> >  https://github.com/apache/geode/tree/rel/v1.2.1.RC4
> >  https://github.com/apache/geode-examples/tree/rel/v1.2.1.RC4
> >
> > Commit ID:
> >  0b881b515eb1dcea974f0f5c1b40da03d42af9cf (geode)
> >  5d034de588a43cdefb8fbb3a6259579785768340 (geode-examples)
> >
> > Source and binary files:
> >  https://dist.apache.org/repos/dist/dev/geode/1.2.1.RC4
> >
> > Maven staging repo:
> >  https://repository.apache.org/content/repositories/orgapachegeode-1027
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >  https://github.com/apache/geode/blob/develop/KEYS
> >
> > pub  4096R/C72CFB64 2015-10-01
> >  Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
> >
> >
> > Anthony
> >
>

Re: Visibility of Skipped tests in Jenkins

[William Markito Oliveira]

Yup. I've tested accessing that same page without any authentication and
seems to work fine here as well..

On Thu, Aug 24, 2017 at 1:29 PM, Mark Bretl  wrote:

> Hi Kirk,
>
> I think you are looking for this page, https://builds.apache.
> org/blue/organizations/jenkins/Geode-nightly/detail/
> Geode-nightly/930/tests?
>
> I see 'Skipped' under the Failed tests.
>
> --Mark
>
> On Thu, Aug 24, 2017 at 11:09 AM, Kirk Lund  wrote:
>
>> In local instances of Jenkins, I can see a list of "Skipped" tests --
>> these are JUnit tests which were skipped because they are marked with
>> @Ignore or because they have an org.junit.Assume check that wasn't
>> satisfied (example: Assume.assumeTrue(isWindows())). I can't figure out
>> where that view is in the ASF Jenkins for Geode Nightly Build. Is it there
>> and I'm just missing it or I have insufficient permissions?
>>
>>
>


-- 
~/William

Re: [DRAFT] Geode Board Report August 2017

[William Markito Oliveira]

LGTM

On Wed, Aug 9, 2017 at 4:29 PM, Joey McAllister 
wrote:

> Looks good.  Thanks, Dan!
>
> On Wed, Aug 9, 2017 at 2:23 PM Anthony Baker  wrote:
>
> > LGTM
> >
> > > On Aug 9, 2017, at 2:01 PM, Mark Bretl  wrote:
> > >
> > > Looks good to me. Thanks Dan for taking the time to create the draft.
> > >
> > > If there are no issues, then I will post this EOD PST.
> > >
> > > --Mark
> > >
> > > On Mon, Aug 7, 2017 at 2:04 PM, Dan Smith  wrote:
> > >
> > >> Hi folks,
> > >>
> > >> Please review the below draft for our report to the board for this
> past
> > >> quarter and offer corrections. As Mark mentioned, we need to submit
> the
> > >> draft this Wednesday.
> > >>
> > >> Thanks!
> > >> -Dan
> > >>
> > >> -
> > >>
> > >> ## Description:
> > >>
> > >> - Apache Geode provides a database-like consistency model, reliable
> > >> transaction processing and a shared-nothing architecture to maintain
> > very
> > >> low
> > >> latency performance with high concurrency processing.
> > >>
> > >> ## Issues:
> > >>
> > >> - There are no issues requiring board attention at this time.
> > >>
> > >> ## Activity:
> > >>
> > >> - Geode 1.2 was released with over 300 tickets resolved, including
> > >>  - Integration with Apache Lucene is no longer experimental
> > >>  - A built in partition resolver
> > >>  - Examples bundled with the distribution
> > >> - ApacheCon presentation - Building an IoT platform with Apache Apollo
> > and
> > >> Apache Geode by Swapnil Bawaskar
> > >>
> > >> ## Health report:
> > >>
> > >> - We’re continuing to work on attracting new contributors and making
> it
> > >> easier
> > >> to participate in the community.
> > >> - Mailing list activity is healthy.
> > >> - Work has started towards the next Geode release, 1.3.0 including
> > >> development of a new client/server protocol.
> > >>
> > >> ## PMC changes:
> > >>
> > >> - Currently 36 PMC members (+1 since last report)
> > >> - Joey McAllister was added to the PMC on Mon Jul 24 2017
> > >>
> > >> ## Committer base changes:
> > >>
> > >> - Currently 81 committers (+2 since last report)
> > >> - Joey McAllister was added as a committer on Tue Jul 25 2017
> > >> - Deepak Dixit was added as a committer on Thu Jul 13 2017
> > >>
> > >> ## Releases:
> > >>
> > >> - 1.2.0 was released on Wed July 17th 2017
> > >>
> > >> ## Mailing list activity:
> > >>
> > >> - Mailing lists remain active and we’re seeing continued growth in
> > >> subscriber
> > >> counts.  Mailing list traffic on dev went down because we redirected
> > jira
> > >> traffic to iss...@geode.apache.org, but the combined activity
> > increased.
> > >>
> > >> - dev@geode.apache.org:
> > >> - 174 subscribers (up 10 in the last 3 months)
> > >> - 4264 emails sent in the past 3 months, 7166 in the previous cycle
> > >>
> > >> - iss...@geode.apache.org:
> > >> - 56 subscribers (up 1 in the last 3 months)
> > >> - 3183 emails sent in the past 3 months, 0 in the previous cycle
> > >>
> > >> - u...@geode.apache.org:
> > >> - 232 subscribers (up 12 in the last 3 months)
> > >> - 286 emails sent in the past 3 months, 202 in the previous cycle
> > >>
> > >> ## JIRA activity:
> > >>
> > >> - 513 JIRA tickets created in the last 3 months
> > >> - 351 JIRA tickets closed/resolved in the last 3 months
> > >>
> >
> >
>

Re: Akka Stream connector

[William Markito Oliveira]

Looks really good Olivier! Thanks for the contribution! I'll give it a run
this week...

On Tue, Jul 4, 2017 at 4:59 AM, Olivier NOUGUIER  wrote:

> Hi,
>   I'm (a little) proud to point you the connector [0] from/to apache geode
> for Akka Stream.
>   It is a first version, only supporting PDX serialization.
>
> Hope you'll appreciate && criticize
>
> [0] http://developer.lightbend.com/docs/alpakka/current/geode.html
>



-- 
~/William

Re: What to do with Singletons

[William Markito Oliveira]

+1 for Geode functions as well.

Back on the day, I've talked with Barry about it and we got a few basic
ones into this repository.

https://github.com/markito/geode-functions

But we should probably create another thread to talk about it to keep this
one focused on the singletons discussion.

On Thu, May 25, 2017 at 8:45 AM, Wes Williams  wrote:

> +1 to utility functions
>
> *Wes Williams | Pivotal Advisory **Data Engineer*
> 781.606.0325
> http://pivotal.io/big-data/pivotal-gemfire
>
> On Wed, May 24, 2017 at 4:59 PM, John Blum  wrote:
>
> > On a side but related note, it would be nice if Geode had the notion of
> > useful, "canned" Functions provided OOTB.  Some of the *Gfsh* functions
> > would be quite useful for applications in fact, or particularly for
> > framework/tools to use as well.  Sometime ago I sent a list of Functions
> I
> > thought would be nice to have.
> >
> > Food for thought.
> >
> > On Wed, May 24, 2017 at 1:41 PM, Kirk Lund  wrote:
> >
> > > Thanks for pointing out that DistributionManager is internal -- I
> forgot
> > > about that. I'm primarily concerned with internal Functions, such as
> > those
> > > for GFSH commands, so maybe an internal version of FunctionContext
> which
> > > exposes more would be good for those.
> > >
> > > On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider <
> > dschnei...@pivotal.io>
> > > wrote:
> > >
> > > > FunctionContext is an external interface so it can not expose
> internal
> > > > interfaces like DistributionManager.
> > > > But it could expose Cache. DistributedSystem is external so you could
> > > have
> > > > it exposed from FunctionContext but it is already exposed from Cache.
> > > > SecurityService is also internal.
> > > > Are you thinking that for internal Functions you would cast
> > > FunctionContext
> > > > to an internal that would then expose these internal classes?
> > > >
> > > >
> > > >
> > > > On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:
> > > >
> > > > > I've been digging through our code with close attention to the
> > > > singletons.
> > > > > I believe the majority of singletons in Geode exist for two main
> > > reasons:
> > > > >
> > > > > 1) Insufficient context or lack of service lookup for Function,
> > > > > DistributionMessage and (Client)Command implementations.
> > > > >
> > > > > 2) Poor OO design. This is where you see code in one class invoking
> > > > > concrete methods on another class outside of its concerns. Many of
> > > these
> > > > > need to be teased apart and replaced with some sort of Observer
> that
> > > > > isolates the reaction from the source of the originating event.
> > > > >
> > > > > Right now my focus is on #1 because that's the area that's
> currently
> > an
> > > > > obstacle for me.
> > > > >
> > > > > Function, DistributionMessage and (Client)Command classes need to
> > have
> > > > more
> > > > > context provided to them (Cache, Security, etc) or they need a
> better
> > > > > mechanism to look up these services. Currently these classes reach
> > out
> > > to
> > > > > singletons in order to "get" what they need.
> > > > >
> > > > > *A) Function*
> > > > >
> > > > > The main entry-point which injects services into the Function is:
> > > > >
> > > > > public void execute(FunctionContext context);
> > > > >
> > > > > The FunctionContext needs to provide the service(s) that any
> Function
> > > > might
> > > > > require. This could include Cache, DistributionManager and maybe
> > > > > SecurityService (anything else?).
> > > > >
> > > > > *B) (Peer-to-peer) DistributionMessage*
> > > > >
> > > > > The main entry-point which injects services into the
> > > DistributionMessage
> > > > > is:
> > > > >
> > > > > protected abstract void process(DistributionManager dm);
> > > > >
> > > > > We could provide multiple arguments or a single new
> > DistributionContext
> > > > > which then provides DistributionManager and Cache (anything else?).
> > > > >
> > > > > *C) (Client) Command*
> > > > >
> > > > > The main entry-point which injects services into the Command is:
> > > > >
> > > > > public void execute(Message msg, ServerConnection servConn);
> > > > >
> > > > > ServerConnection is huge but it does already expose Cache.
> > BaseCommand
> > > is
> > > > > the only Command that implements "execute" and it defines a new
> > > > entry-point
> > > > > for injection:
> > > > >
> > > > > abstract public void cmdExecute(Message msg, ServerConnection
> > servConn,
> > > > > long start) throws IOException, ClassNotFoundException,
> > > > > InterruptedException;
> > > > >
> > > > > We might want to clean that up and define a new CommandContext
> which
> > > > > provides the Cache or anything else that the Command may need.
> > > > >
> > > > > Thoughts or additional ideas?
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>



-- 
~/William

Re: [gemfire-dev] New Client-Server Protocol Proposal

[William Markito Oliveira]

+1

I think I've shared this before, but Kafka also has good (tabular)
representation for messages on their protocol.

- https://kafka.apache.org/protocol#protocol_messages
- https://kafka.apache.org/protocol#protocol_message_sets

On Mon, May 8, 2017 at 4:44 PM, Ernest Burghardt 
wrote:

> Hello Geodes!
>
> Good discussion on what/how the messages will be/handled once a connection
> is established.
>
> +1 to a simple initial handshake to establish version/supported features
> that client/server will be communicating.
>
> From what I've seen so far in the proposal it is missing a definition for
> the "connection"/disconnect messages.
> - expected to see it here:
> https://cwiki.apache.org/confluence/display/GEODE/Generic+System+API
>
> From a protocol perspective, this is currently a pain point for the
> geode-native library.
>
> As Jake mentioned previously, having messages that are class-like and have
> a singular job helps client developers by having an explicit protocol to
> follow.
>
>
> The basic case a developer is going to exercise is to connect/disconnect.
> How to do this should be straightforward from the start.
>
> Geode probably does not need a 7 Layer OSI stack, but it might make sense
> to have a couple layers:
>
> 1 - transport  (network socket)
> 2 - protocol   (version/features)
> 3 - messaging (do cluster work)
>
> e.g.
> client library opens a socket to the server (layer 1 - check)
> client/server perform handshake and the connection is OPEN (layer 2 -
> check)
> pipe is open for business, client/server do work freely (layer 3 - check)
>
> When this is sorted out I think a couple simple sequence or activity
> diagrams would be very helpful to the visual-spatial folks in the
> community.
>
>
> Best,
> Ernie
>
> ps.  one consideration for message definition might be to use a more
> tabular presentation of messages followed by any
> definitions/cross-referencing... this is an example from a CDMA protocol I
> have worked with in the past
>
> Location assignment message
>
> Field
>
> Length (bits)
>
> MessageID
>
> 8
>
> TransactionID
>
> 8
>
> LocationType
>
> 8
>
> LocationLength
>
> 8
>
> LocationValue
>
> 8 × LocationLength
>
>1.
>
>MessageID   The access network shall set this field to 0x05.
>2.
>
>TransactionID  The access network shall increment this value for
>each new LocationAssignment message sent.
>
>   LocationType   The access network shall set this field to the
> type of the location as specified in Table
>
>
>
>
>
> [image: page144image36968] [image: page144image37392] [image:
> page144image37976] [image: page144image38560] [image:
> page144image38984] [image:
> page144image39408]
>
>
>
>
>
>
>
> On Mon, May 8, 2017 at 7:48 AM, Jacob Barrett  wrote:
>
> > On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra 
> > wrote:
> >
> > >
> > > 0. In first phase we are not doing chunking/fragmentation. And even
> this
> > > will be option for client.(
> > > https://cwiki.apache.org/confluence/display/GEODE/
> Message+Structure+and+
> > Definition#MessageStructureandDefinition-Protocolnegotiation
> > > )
> > >
> >
> > I highly suggest initial handshake be more relaxed than specific "version
> > number" or flags. Consider sending objects that indicate support for
> > features or even a list of feature IDs. At connect server can send list
> of
> > feature IDs to the client. The client can respond with a set of feature
> IDs
> > it supports as well as any metadata associated with them, say default set
> > of supported encodings.
> >
> >
> > > 1. Are you refereeing websocket/spdy? But I think we are talking almost
> > > same thing, may be push isPartialMessage flag with chunk
> length(Anthony's
> > > example below) ?
> > >
> >
> > I am not sure what you mean here but if you are talking about layering a
> > channel protocol handler then I guess yes. The point is that each of
> these
> > behaviors should be encapsulated in specific layers and not intermixed
> with
> > the message.
> >
> >
> > > 2. That's the part of the problem. Even if you need to serialize the
> > > "String", you need to write length first and then need to write
> > serialized
> > > utf bytes. We can implement chunked input stream and can de-serialize
> the
> > > object as it is coming (DataSerializable.fromData(ChunkedStream)).
> > >
> >
> > Right, and in this case the length is never the length of the string, it
> is
> > the length of the byte encoding of the string. This is not known until
> the
> > encoding is complete. So by chunking we can write the length of smaller
> > buffers (from buffer pools) as the length of that sequence of bytes, the
> > last chunk terminated with length 0. Each of those chunks can be based
> to a
> > UTF-8 to UTF-16 transcoder to create the String.
> >
> > -Jake
> >
>



-- 
~/William

Re: [gemfire-dev] New Client-Server Protocol Proposal

[William Markito Oliveira]

+1 for that as well
On Thu, May 4, 2017 at 5:21 PM Dan Smith  wrote:

> >
> > I wouldn't tackle that at this layer. I would suggest adding a layer
> > between the message and TCP that creates channels that are opaque to the
> > message layer above. The message layer wouldn't know if it was talking to
> > multiple sockets to the client or single socket with multiple channels.
> >
>
> ++1 on that!
>

Re: Simple Java Client

[William Markito Oliveira]

This is an awesome discussion and Jake's hitting all the right notes about
why JCache is a good idea! I've fought that fight in the past and lost it
but I'm happy to see it coming back...

What's really nice about Geode is that the functionalities and capabilities
are all there, they're just not that well exposed, known by others or
obscured by some decisions that doesn't apply anymore.

It's the same conversation about monitoring and statistics...  All the
capability is there with JMX and Stats, but using an unknown custom format
or tool to display that data makes it not very appealing for OSS and
enterprise users that need workarounds and hacks to integrate with common
monitoring tools.

Refactoring API Client APIs, documentation and implementation of a new
Protocol, Reactive APIs, better integration with standard monitoring tools
-  Sounds like good points for a 2.0 roadmap IMHO.


On Wed, Apr 26, 2017 at 10:28 AM, Jacob Barrett  wrote:

> Wes,
>
> Those are almost all administrative commands and have no place on the
> client API. They belong on an administrative API or as I'm arguing a series
> of MBeans/JMX as it is already an established standard.
>
> -Jake
>
> On Wed, Apr 26, 2017 at 8:09 AM Wes Williams  wrote:
>
> > Now we're getting some precision. Let's talk about the "raw" Geode
> > proprietary bad ass API!  Would that "raw" Geode proprietary bad ass API
> > "raw"
> > Geode proprietary bad ass API that we're talking about be centered around
> > the commands found here:
> >
> > https://github.com/apache/geode/tree/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/cli/commands
> >
> > Or somewhere else?
> >
> > *Wes Williams | Pivotal Advisory **Data Engineer*
> > 781.606.0325
> > http://pivotal.io/big-data/pivotal-gemfire
> >
> > On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett 
> > wrote:
> >
> > > Java and its community have standards for all of these issue so why
> > > re-invent the wheel. The market doesn't want proprietary anymore, they
> > want
> > > standards and mobility.
> > >
> > > Configuration of the server should happen through MBeans. You can wrap
> > that
> > > in gfsh for command line, REST for remote web based admin, use JConsole
> > or
> > > any other number of JMX based enterprise management tools. By using
> > MBeans
> > > the server can easily expose new discovered services without the need
> to
> > > code specific gfsh commands, REST interfaces or APIs. There is no
> reason
> > my
> > > SDG can't be retooled to "discover" the configuration from these MBeans
> > as
> > > well rather than having to be touched every time we add or change
> > > something. There are tools and books already written that implementors
> > can
> > > consult on MBeans. There isn't anything out there on gfsh commands.
> > >
> > > If we want to play in the Java community, especially J2EE (the other
> 50%
> > of
> > > Java that isn't Spring), then we had better have a JSR-107 answer no
> > matter
> > > what the pain is to provide it. I can pull dozens of books of the shelf
> > > that teach me how to effectively use a JCache, how many can I pull off
> > the
> > > shelf that teach me Geode's API? How many engineers can I get
> > applications
> > > form by saying "must have Geode API knowledge"? I can find people with
> > > JCache knowledge though. So from in implementor's perspective having
> > > standards is a must. Now I don't think the JSR-107 interface should be
> > the
> > > root interface but rather a facade on the "raw" Geode proprietary bad
> ass
> > > API. That API should be 100% asynchronous (reactive, SEDA, whatever the
> > > current buzzword for asynchronous is today). Around that API we can
> > provide
> > > facades for JSR 107, ConcurrentMap (our current yet not so well
> behaving
> > > API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of
> putting
> > > all those features into a single API makes my head exploded and they
> > don't
> > > need to be like they are today.
> > >
> > >
> > >
> > > On Tue, Apr 25, 2017 at 8:25 PM Wes Williams 
> > wrote:
> > >
> > > > A couple of points to interact with John's points.
> > > >
> > > > GFSH as API
> > > >
> > > > We agree that GFSH is a DSL, and a really good and useful one. We
> agree
> > > > that we don't want our API tied to GFSH syntax. I view the valuable
> > part
> > > of
> > > > GemFire admin as the Java code underneath GFSH, or the "Commands."
> > > >
> > > > For example, to create a JAVA API to "Create Region",  why not
> create a
> > > > Java API around CreateAlterDestroyRegionCommands? In this way, GFSH
> and
> > > the
> > > > JAVA API share the same code. It seems too obvious yet I don't see it
> > > being
> > > > recommended.  Why not?  (Note: the hard-coded formatting would need
> to
> > be
> > > > removed).
> > > >
> > > > Once you have the Java/GFSH/REST API as common code, you then
> refactor
> > > it.
> > > > 

Re: One class loader vs multiple class loaders for deployed jars

[William Markito Oliveira]

Just adding another spin to this discussion...  Today the idea of
"application"  inside a Geode cluster is really hard to define, there is no
real concept of multitenancy and that also makes the problem of deployed
jar isolation harder.

How would you define the hierarchy of a deployed jar from App 1 vs App 2 ?
There is no concept of application, the main constructs are clients,
servers, regions, functions, callbacks.  In the current architecture I
believe such isolation could happen with "user space" - Where users are
considered for isolation (userA can't see jars deployed by userB unless
specified so) creating then some sense of hierarchy.   But I'm not really
sold on this idea as well because it mixes two different concepts, so just
thinking out loud.

But going back to my main observation, we could try to answer how
multinenancy could be implemented in Geode and use that to solve other
problems like classloader hierarchy.

+1 for options #1 for now as well.

On Tue, Apr 11, 2017 at 12:22 PM, Kirk Lund  wrote:

> I think this comes down to two current (realistic) options:
>
> 1) accept Jared's changes as are so we can avoid forced loading of all
> deployed jars up front (GEODE-2290 will be fixed in the next release)
> 2) reject the changes until someone has time to retrofit Geode with a new
> CL container (GEODE-2290 will not be fixed in the next release)
>
> My choice is #1 -- I'm for accepting and applying the current changes to
> develop (deploy jar will then replace one CL for all deployed jars every
> time you deploy any jars).
>
> What do others want to do?
>
> On Tue, Apr 11, 2017 at 10:06 AM, Jared Stewart 
> wrote:
>
> > I would like to distinguish between the following two objectives:
> >  1) Do not eagerly load every class contained in a deployed jar
> >  2) Establish robust classloader isolation for deployed jars
> >
> > The aim of my current line of work is to fix 1) (GEODE-2290).  This is
> not
> > to say that 2) is not a valuable pursuit, but I think getting 2) done
> > correctly is a larger task than fixing 1) in isolation.
> >
> > To get into the specifics of the libraries you mentioned,
> >
> > JCL:
> >  - JCL has no support for removing/undeploying jars.  In this respect, I
> > don't see anything that JCL would add over simply using a URLClassLoader.
> > We would have to rebuild the JCL class loader in exactly the same set of
> > circumstances that we would need to rebuild a URLClassLoader.
> >  - I have seen a fair number of warnings from people that JCL is buggy
> and
> > incomplete, e.g. (http://stackoverflow.com/ques
> > tions/60764/how-should-i-load-jars-dynamically-at-runtime#
> > comment43066872_1450837)  This would seem to be supported by a quick look
> > at the github issues page for JCL, which includes things like a bug
> report
> > of a deadlock from Jun 2016 to which the developers have never responded.
> >
> > JBoss Modules:
> >  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> > direction towards which to strive.  Yet the fact that they require an
> > external module descriptor (XML) would again seem to make this a much
> > larger task than 1) alone.  (If the idea here is to have a user provide
> us
> > with a JBoss Module rather than a plain jar file, this would be a large
> > breaking change for existing users.  On the other hand, if the idea is
> for
> > us to autogenerate the necessary metainformation to transform the user's
> > jar file into a JBoss Module, this would seem to be a large task which is
> > again independent from the goals of 1).
> >
> > - Jared
> >
> > > On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
> wrote:
> > >
> > > There are certainly many projects in the OS community that have solved
> > this
> > > same problem. Perhaps we can find a class loader from a project that
> > would
> > > suite this need.
> > >
> > > Quick search of standalone frameworks comes up with a few popular hits:
> > > https://github.com/kamranzafar/JCL
> > > https://github.com/jboss-modules/jboss-modules
> > >
> > > -Jake
> > >
> > >
> > >
> > >
> > > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> > >
> > >> I think Jared started down this path because we had a custom
> classloader
> > >> implementation that he was trying to get rid of -- that impl was
> pretty
> > >> limited and forced loading of all classes up-front.
> > >>
> > >> Now the code uses fast classpath scanner and that old custom
> classloader
> > >> can't be used. The old classloader is so simplistic and limited that
> > trying
> > >> to modify it looks like more work than writing a new one from scratch.
> > >> Implementing a new custom classloader or switching our codebase to
> use a
> > >> new classloader container (using an existing solution) are both
> possible
> > >> directions. Until that's completed the "deploy jar" command will
> > continue
> > >> to force ALL classes to be loaded up-front.
> > >>
> > 

Re: Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[William Markito Oliveira]

Hi Anthony,

My karma is also limited, sorry.  I believe only Roman (or infra) can
change that...

On Mon, Apr 10, 2017 at 11:46 AM, Anthony Baker  wrote:

> Anyone?
>
> > On Apr 7, 2017, at 11:32 AM, Anthony Baker  wrote:
> >
> > I would like Jenkins karma so I can explore running our tests from
> within a docker container.  William / Mark / Roman can you help me out?
> >
> > Thanks,
> > Anthony
> >
> >
> >> On Mar 21, 2017, at 3:14 PM, Anthony Baker  wrote:
> >>
> >> Would be very nice to run our jenkins jobs from a docker container to
> avoid these environmental quirks.
> >>
> >> Anthony
>
>


-- 
~/William

Re: Orphaned Server processes

[William Markito Oliveira]

Jianxia, you can set the property "start-locator" in gemfire.properties as
below...  So the server then will have an embedded locator.

http://geode.apache.org/docs/guide/11/reference/topics/gemfire_properties.html
start-locator If set, automatically starts a locator in the current process
when the member connects to the distributed system and stops the locator
when the member disconnects.

To use, specify the locator with an optional address or host specification
and a required port number, in one of these formats:

start-locator=address[port1]

start-locator=port1

If you only specify the port, the address assigned to the member is used
for the locator.

If not already there, this locator is automatically added to the list of
locators in this set of gemfire properties.
*not set*

On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:

> Hi Darrel,
>
> How to configure a colocated locator in the same server process? Just
> curious. What I understand is that the locator is in its own process.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
> wrote:
>
> > I like the idea of servers failing to start if no locator exists.
> > But does a use case for a server with no locator exist? What about ease
> of
> > development?
> >
> > I could see that it would be easier to start just a single server process
> > instead of two (locator and server). But for this use case couldn't the
> > developer just configure a colocated locator in the same server process?
> > This would have the benefit of the clients during development and
> > production using a locator consistently.
> >
> > Is it true that the server with no locator will never have any peer
> members
> > in its cluster?
> > Clients can still connect to this singleton server by being configured
> with
> > the server host and port instead of the locator.
> >
> >
> > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
> >
> > > Without connecting to the server, I think you can still stop it by
> > > specifying --pid or --dir in "stop server" command.
> > >
> > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > > wrote:
> > >
> > > > Hey there,
> > > >
> > > > Current Geode allows a user to start a server without being linked
> to a
> > > > Locator. Which in itself is not incorrect, but once started there is
> no
> > > way
> > > > to connect to that server to manage it.
> > > >
> > > > I know that we have taken an opinionated view that member discovery
> can
> > > > only now happen through a locator and that multicast is an option
> > > anymore.
> > > >
> > > > Can we take the same opinionated view where we either state that
> unless
> > > > your server is connecting to a locator, it cannot be started OR we
> fix
> > > the
> > > > default behavior where we can start a server but cannot connect to
> it,
> > > and
> > > > have to resort to "kill -9" commands to kill the server.
> > > >
> > > > --Udo
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>



-- 
~/William

Re: [DISCUSS] security threats (was Re: [CVE-2017-5649] Apache Geode information disclosure vulnerability)

[William Markito Oliveira]

Looks like a great wiki page to me. ;)

Cool summary Anthony! 

Sent from my iPhone

> On Apr 5, 2017, at 11:49 AM, Anthony Baker  wrote:
> 
> As a follow up to this CVE, I wanted to share the process for reporting and 
> responding to security issues:
> 
> https://www.apache.org/security/
> https://www.apache.org/security/committers.html
> 
> Here’s the short version:
> 
> - Report the vulnerability privately (secur...@apache.org | 
> priv...@geode.apache.org)
> - Fix the vulnerability
> - Release a new version(s) with the fix
> - Disclose the vulnerability
> 
> Secondly, I think it would be valuable to get the community’s perspective on 
> the kinds of security threats that a Geode deployment may encounter.  Here 
> are a few questions to spark the conversation:
> 
> - When is a bug a security bug?
> - When does a bug require a CVE and disclosure?
> - How do we know how severe a security issue is?
> - How soon do we need to respond to a security issue?
> 
> Anthony
> 
>> On Apr 4, 2017, at 7:31 AM, Anthony Baker  wrote:
>> 
>> CVE-2017-5649: Apache Geode information disclosure vulnerability
>> 
>> Severity:  Medium
>> Base score:  5.5 (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L)
>> 
>> Vendor:
>> The Apache Software Foundation
>> 
>> Versions Affected:
>> Geode 1.1.0
>> 
>> Description:
>> When a cluster has enabled security by setting the security-manager
>> property, a user should have DATA:READ permission to view data stored
>> in the cluster.  However, if an authenticated user has CLUSTER:READ
>> but not DATA:READ permission they can access the data
>> browser page in Pulse.  From there the user could execute an OQL query
>> that exposes data stored in the cluster.
>> 
>> Mitigation:
>> 1.1.0 users should upgrade to 1.1.1
>> 
>> Credit:
>> This issue was discovered by Jinmei Liao.
>> 
>> References:
>> https://www.apache.org/security/
> 

Re: [gemfire-dev] More detailed Geode Modularization proposal

[William Markito Oliveira]

Since the modularization effort may take a significant time and one of the
big features of Java 9 is modularization, why not leverage the
infrastructure of the JDK [1] for that ?  This would not only bring the
modularization but also make it 100% compatible with Java 9.

It also provide solutions around class-loaders [2].

Food for thought... :)

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules
[2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#class-loaders

On Wed, Mar 29, 2017 at 3:29 PM, Jared Stewart  wrote:

> I have some questions about the ClassLoader isolation proposal. If the
> class loaders of different modules are truly isolated, how can any module
> load classes from a different module?  And conversely, if different modules
> can load classes from each other, how can they truly be isolated?  In
> something like an application server, this seems much simpler, since the
> wars that get deployed to an app server should never need to interact with
> each other.  But how can this work with Geode modules?
>
> > On Mar 29, 2017, at 10:00 AM, Udo Kohlmeyer 
> wrote:
> >
> > Hi there Guys,
> >
> > A more detailed proposal for a more modular Geode is available. Please
> review and comment, either on this thread or on confluence.
> >
> > https://cwiki.apache.org/confluence/display/GEODE/
> Geode+Modularization+-+An+approach
> >
> > Udo
> >
>
>

Geode deployment logos

[William Markito Oliveira]

Are there any deployments of Geode out there interested in displaying their
logo in our Deployments section of the Community page ?

http://geode.apache.org/community/

Re: Permission to Edit and Comment

[William Markito Oliveira]

You should be good to go now Sarge... :)

On Wed, Mar 29, 2017 at 1:19 PM, Michael William Dodge 
wrote:

> May I have the necessary permissions such that I can edit and comment on
> wiki articles under https://cwiki.apache.org/confluence/display/GEODE/ <
> https://cwiki.apache.org/confluence/display/GEODE/> ? Thanks.
>
> Sarge




-- 
~/William

Re: Apache Geode no longer uses tools.jar or Attach API by default

[William Markito Oliveira]

That's awesome Kirk, thanks! 

Sent from my iPhone

> On Mar 9, 2017, at 9:02 PM, Kirk Lund  wrote:
> 
> I just committed the changes for GEODE-2594. With this change in place,
> Apache Geode no longer uses or requires the tools.jar or Attach API by
> default, and the gfsh scripts no longer add the tools.jar to the classpath.
> 
> This means anyone who is maintaining Docker images or anything similar can
> update the image to use a JRE instead of the JDK.
> 
> First release with this change will be Apache Geode 1.2.0.
> 
> The following is the only visible change to users:
> 
> The --pid option for status locator, status server, stop locator, stop
> server commands are deprecated in gfsh help and will not work by default.
> If any user wants to use the --pid options, then you would need to add the
> tools.jar to your CLASSPATH before using gfsh. No other changes should be
> required.
> 
> commit 492d01add96f878d09e2193201c6354680900b3f
> Author: Kirk Lund 
> Date:   Wed Mar 8 14:13:14 2017 -0800
> 
>GEODE-2594: do not use Attach API or tools.jar by default
> 
>* remove tools.jar from classpath in gfsh and gfsh.bat
>* remove use of Attach API from start commands
>* deprecate --pid option in help of status and stop commands
> 
>If a user still wants to use the --pid option in status or
>stop commands then they can manually add the tools.jar to
>their classpath before launching gfsh.

Re: for discussion: separate website into its own repo

[William Markito Oliveira]

+1

On Fri, Feb 17, 2017 at 4:15 PM, Karen Miller  wrote:

> Seems like everyone is in favor of the separate repo.  I'll request one
> early next week.
> I created https://issues.apache.org/jira/browse/GEODE-2507 to handle the
> first parts
> of the task of getting the new repo up and running.
>
>
> On Fri, Feb 17, 2017 at 9:25 AM, Kirk Lund  wrote:
>
> > +1
> >
> > On Thu, Feb 16, 2017 at 4:45 PM, Joey McAllister  >
> > wrote:
> >
> > > +1 to Karen's suggestion of moving the website to its own repo.
> > >
> > > +1 to Dan's suggestion scripting the website build/publishing with a CI
> > > system based on commits.
> > >
> > > On Thu, Feb 16, 2017 at 4:38 PM Dan Smith  wrote:
> > >
> > > > +1
> > > >
> > > > I think the current setup is confusing, because the website is
> supposed
> > > to
> > > > include docs that are generated from the last release, but the site
> > > > instructions say the site should be generated from develop. A
> separate
> > > repo
> > > > with a single branch will probably reduce confusion.
> > > >
> > > > We also need to script the website building and publishing, and
> ideally
> > > > have the publishing done by a CI system based on commits. It looks
> like
> > > > some other projects are talking about doing this with jenkins
> jenkins -
> > > see
> > > > INFRA-10722 for example.
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Feb 16, 2017 at 4:10 PM, Karen Miller 
> > > wrote:
> > > >
> > > > > I think that the website content that is currently in
> > geode/geode-site
> > > > > ought to be moved to its own repository.  The driving reason for
> this
> > > is
> > > > > that changes to the website occur on a different schedule than code
> > > > > releases.  We often want to add a new committer's name or a new
> > > > > event, and these items are not associated with sw releases. A new
> > > website
> > > > > release that comes from the develop branch may have commits that
> > > > > should not yet be made public.
> > > > >
> > > > > Are there downsides to separating the website content into its own
> > > repo?
> > > > >
> > > >
> > >
> >
>



-- 
~/William

Re: Automating docker builds for geode-native

[William Markito Oliveira]

What about creating a .dockerignore file ?  ->
https://docs.docker.com/engine/reference/builder/#/dockerignore-file



On Fri, Feb 17, 2017 at 10:02 AM, Anthony Baker  wrote:

>
> > On Feb 10, 2017, at 12:29 PM, Anthony Baker  wrote:
> >
> > The geode-native build, like most c++ projects, requires a fairly
> specific toolchain.  Now that we have a docker build environment [1], I’d
> like to ask INFRA to automate the creation and publishing of docker images
> for geode-native.  This can be done by integrating GitHub / DockerHub [2].
> Note that the docker image would *only* be for build purposes and would not
> contain source or binaries from geode-native.  By publishing our build
> toolchain in a docker image:
> >
> > 1) it makes contributing easier
> > 2) it makes our travis-ci builds faster (currently at ~30min)
> > 3) it paves the way to create a nightly Jenkins job for geode-native
> >
> > I suggest publishing this image under the apache namespace [3] as
> geode-native-build.  Thoughts?
> >
> > Anthony
> >
> > [1] https://github.com/apache/geode-native/blob/develop/
> docker/Dockerfile
> > [2] https://issues.apache.org/jira/browse/INFRA-11584?jql=
> project%20%3D%20INFRA%20AND%20text%20~%20docker
> > [3] https://hub.docker.com/u/apache/
>
> It turns out there are some quirks with automated docker builds.  The
> docker container will get rebuilt based on pushes to specific branches or
> when tags are created that match a regex pattern.  This is not super useful
> when the container is used to define a build environment.  For now, I just
> manually pushed the build image to our docker hub account as:
>
> apachegeode/geode-native-build
>
> We could consider using this automation to build release images.  However,
> the Dockerfile must live in the project root and the container size becomes
> larger than just downloading the binaries we publish on ASF.
>
> Anthony
>
>


-- 
~/William

Re: [DISCUSS] JIRA guidelines

[William Markito Oliveira]

+1 

Finally!! ;)

Sent from my iPhone

> On Feb 14, 2017, at 7:59 PM, Galen M O'Sullivan  wrote:
> 
> +1 to the article and removing the draft label
> 
>> On Tue, Feb 14, 2017 at 4:05 PM, Akihiro Kitada  wrote:
>> 
>> I agree!
>> 
>> 
>> --
>> Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
>> Support.Pivotal.io   |  Mon-Fri  9:00am to
>> 5:30pm JST  |  1-877-477-2269
>> [image: support]  [image: twitter]
>>  [image: linkedin]
>>  [image: facebook]
>>  [image: google plus]
>>  [image: youtube]
>> 
>> 
>> 
>> 2017-02-15 8:47 GMT+09:00 Dan Smith :
>> 
>>> We have this draft of JIRA guidelines sitting on the wiki. I updated it
>>> slightly. Can we agree on these guidelines and remove the draft label? Is
>>> there more that needs to be here?
>>> 
>>> https://cwiki.apache.org/confluence/pages/viewpage.
>> action?pageId=57311462
>>> 
>>> -Dan
>>> 
>> 

Re: GeodeRedisAdapter improvments/feedback

[William Markito Oliveira]

Definitely not by asking in the middle of on-going  discussion threads. 

Instructions: http://bfy.tw/A5ub :)

Sent from my iPhone

> On Feb 14, 2017, at 6:38 PM, Michael Vos  wrote:
> 
> How do I unsubscribe from this email list?
> 
> Thank you, 
> 
> Michael Vos
> Strategic Partnerships
> 310-804-7223 | m...@pivotal.io
> 
> 
> 
> 
> 
>> On Feb 14, 2017, at 3:37 PM, Dan Smith  wrote:
>> 
>> I also had a hard time reading this. It sounds like the tl;dr is that your 
>> are proposing storing each redis collection in a single region entry, rather 
>> than a a partition region? I guess the question is whether users will have a 
>> few very large collections that need to be partitioned, or lots and lots of 
>> really tiny collections. I'm not quite sure what the more common use case is.
>> 
>> -Dan
>> 
>>> On Tue, Feb 14, 2017 at 3:22 PM, Swapnil Bawaskar  
>>> wrote:
>>> The Redis adapter was designed so that we can scale all the Redis data 
>>> structures horizontally. If you bring the data structures to region entry 
>>> level, there is no reason for anyone to use our implementation over Redis.
>>> 
 On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  wrote:
 Hi Hitesh,
 
 Not sure about everyone else, but I had a hard time reading this,  however 
 I think I figured out what you were describing... the only part I still am 
 unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean 
 you want feedback and voting on whether both behaviors are desired?  As in 
 old implementation and new implementation?
 
 2,3,4)  The new implementation would mean all the data for a specific data 
 structure is contained in a single bucket.  So the individual data 
 structures are not quite scalable.  How would you allow scaling of a 
 single data structure?
 
 On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
 In what format do you want the feedback Hitesh?  For now I’ll just comment:
 
 1. Redis Type String
 No comments except that a future Geode value-add would be to extend the 
 Jedis client so that the K/V’s are not compressed. In this way OQL and CQ 
 will work.  The tradeoff of this is that the data cannot be read by a 
 native redis client but for Geode users it’s great. Call the new client 
 Geodis.
 
 2. List/ Hash/ Set/ SortedSet
 Creating a separate region for each creates a constraint that the keys are 
 limited to the characters for region names, which are A-z/0-9/ - and _.  
 Everything else is out. Redis users might start asking questions why their 
 list named ++^^/## throws an error. Your suggestion to make it a key 
 rather than a region solves this. Furthermore, creating a new region every 
 time a new Redis collection is created is going to be slow. I’m not sure 
 why a region was created but I’m sure it made sense to the developer at 
 the time.
 
 7. Default Config
 Can’t we configure a gfsh option to default to the region types we want?  
 Customer A will want PARTITION but Customer B will want 
 PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a 
 geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT 
 that makes _all_ Redis regions of that type?
 
 
 
 On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra 
 > wrote:
 
 Current GeodeRedisAdapter implementation is based on 
 https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal.
 We are looking for some feedback on Redis commands and their mapping to 
 geode region.
 
 1. Redis Type String
   a. Usage Set k1 v1
   b. Current implementation creates "STRING_REGION" geode-partition-region 
 upfront
   c. This k1/v1 are geode-region key/value
   d. Any feedback?
 
 2. List Type
   a. usage "rpush mylist A"
   b. Current implementation maps each list to geode-partition-region(i.e. 
 mylist is geode-partition-region); with the ability to get item from 
 head/tail
   c. Feedback/vote
   -- List type operation at region-entry level;
   -- region-key = "mylist"
   -- region-value = Arraylist (will support all redis list ops)
   d. Feedback/vote: both behavior is desirable
 
 
 3. Hashes
   a. this represents field-value or java bean object
   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
   c. Current implementation maps each hashes to 
 geode-partition-region(i.e. user1000 is geode-partition-region)
   d. Feedback/vote
 -- Should we map hashes to region-entry
 -- region-key = user1000
 -- region-value = map
 -- This will provide java bean sort to behaviour with 10s of 
 

Re: geode git commit: GEODE-2421: Adding packer portion of making a VS2015 dev AMI

[William Markito Oliveira]

+1 for packer scripts. With Jake's readme everyone should be able to use it as 
a standard way to build environment for the native client.  

Thanks for sharing that!

Sent from my iPhone

> On Feb 2, 2017, at 7:20 PM, Michael Martell  wrote:
> 
> For those unfamiliar with packer, or looking for the simplest path to
> building and learning the code, it may be advantageous to post the steps
> for each platform. Personally, I like to learn new code by stepping thru
> examples in the debugger. I'd be happy to post my setup for debugging the
> Geode C++ client on Windows 10 with Visual Studio and OSX with Xcode.
> 
> Mike
> 
>> On Thu, Feb 2, 2017 at 4:41 PM Jacob Barrett  wrote:
>> 
>> I have a readme started that I will commit when I am back from vacation in
>> a week.
>> On Thu, Feb 2, 2017 at 4:36 PM Anthony Baker  wrote:
>> 
>>> +1 for a README
>>> 
>>> I started on a Dockerfile so we could run a job on builds.apache.org.  I
>>> haven’t been able to get back to it recently but here’s a rough draft:
>>> 
>>> FROM ubuntu
>>> MAINTAINER Apache Geode Geode 
>>> 
>>> ARG GEODE_VERSION
>>> 
>>> RUN \
>>>  apt-get update && \
>>>  apt-get -y upgrade && \
>>>  apt-get install -y build-essential && \
>>>  apt-get install -y cmake && \
>>>  apt-get install -y doxygen && \
>>>  apt-get install -y git && \
>>>  apt-get install -y openjdk-8-jdk && \
>>>  apt-get install -y wget && \
>>>  apt-get install -y zlib1g-dev && \
>>>  rm -rf /var/lib/apt/lists/*
>>> 
>>> RUN \
>>>  wget
>>> 
>> https://builds.apache.org/job/Geode-nightly/lastSuccessfulBuild/artifact/geode-assembly/build/distributions/apache-geode-${GEODE_VERSION}.tar.gz
>>> && \
>>>  tar xzf apache-geode-${GEODE_VERSION}.tar.gz && \
>>>  ls /
>>>  #rm apache-geode-${GEODE_VERSION.tar}.tar.gz
>>> 
>>> ENV GEODE /apache-geode-${GEODE_VERSION}
>>> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
>>> 
>>> CMD ["bash"]
>>> 
>>> 
>>> As far as releases go, I think we should start with a source-only release
>>> (after all that’s the only *officially* recognized artifact anyway).  If
>> we
>>> want to create binary convenience artifacts for a release, I would be
>>> hesitant to go beyond linux because multi-platforms builds impose a large
>>> burden on the Release Manager.
>>> 
>>> Anthony
>>> 
 On Feb 2, 2017, at 4:26 PM, Dan Smith  wrote:
 
 It does seem like this stuff needs a README on how to use it.
 
 Are we going to need these images do a release of the native client
>> code?
 How many of these platforms will we need to build on to release the
>>> native
 client?
 
 -Dan
 
 On Thu, Feb 2, 2017 at 3:43 PM, Jacob Barrett 
>>> wrote:
 
> Think of it as a Dockerfile for things not Docker, like Solaris and
> Windows. It describes and can build a machine capable of compile or
> developing the native client. The toolchain is slightly more
>> complicated
> than the Java side. Currently the Packer files are implemented for AWS
>>> but
> can easily be modified to support other virtualization platforms like
> VMWare, OpenStack, etc.
> 
> -Jake
> 
> 
> On Thu, Feb 2, 2017 at 3:38 PM Ernest Burghardt <
>> eburgha...@pivotal.io>
> wrote:
> 
>> Hi Mark,
>> 
>> Our thinking was to make our packer (and associated) scripts
>> available
> such
>> that a community member could use them to create a VM that would be
>>> very
>> equivalent to our build environment.
>> There is some info/documentation that would need to be created to
>> show
> how
>> to do this, but it should be possible for an individual to make
>> images
> like
>> we do in our pipeline.
>> 
>> Best,
>> Ernie
>> 
>> On Thu, Feb 2, 2017 at 3:07 PM, Mark Bretl 
>> wrote:
>> 
>>> Hi,
>>> 
>>> How does/will this help the community?
>>> 
>>> --Mark
>>> 
 On Thu, Feb 2, 2017 at 2:25 PM,  wrote:
 
 Repository: geode
 Updated Branches:
 refs/heads/next-gen-native-client-software-grant e79c4072b ->
>>> 340f2fca8
 
 
 GEODE-2421: Adding packer portion of making a VS2015 dev AMI
 
 This closes #384
 
 
 Project: http://git-wip-us.apache.org/repos/asf/geode/repo
 Commit:
>> http://git-wip-us.apache.org/repos/asf/geode/commit/340f2fca
 Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/340f2fca
 Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/340f2fca
 
 Branch: refs/heads/next-gen-native-client-software-grant
 Commit: 340f2fca80d9388155ed0911712f9a830211b32b
 Parents: e79c407
 Author: Ernest Burghardt 
 Authored: Thu Feb 2 14:03:10 2017 -0800
 

ApacheCon/Big Data 2017 - Anyone attending or submitting talks ?

[William Markito Oliveira]

CFP closes on Feb 11th.

http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp

Re: New proposal for type definitons

[William Markito Oliveira]

I think bson already stores the field names within the serialized data
values, which is indeed more generic but would of course take more space.

These conversations are very interesting, specially considering how many
popular serialization formats exists out there (Parquet, Avro, Protobuf,
etc...) but I'm not sure the serialization itself was the main thing with
Udo's proposal and more the problem that today JSONFormatter + PDXTypes is
the only way to do it and it could cause the "explosion of types" on
unstructured data.

Seems to me that fixing the JSONFormatter to be smarter about it is a quick
path but it would not address the whole picture of making serialization
options modular in Geode which could be it's own new proposal as well.
 Just a thought.

On Tue, Jan 3, 2017 at 7:21 PM, Jacob Barrett  wrote:

> I don't know that I would be concerned with optimization of unstructured
> data from the start. Given that the data is unstructured it means that it
> can be restructured at a later time. You could have a lazy task running on
> the server the restructures unstructured data to be more uniform and
> compact.
>
> I also don't think there are many good reasons to try wedge this into PDX.
> The only reason I see for wedging this into PDX is to avoid progress on
> modularizing and extending Geode.
>
> If all the where we access fields on a stored object, query, indexing,
> etc., where made a bit more generic then any object that supports a simple
> getValue(field) like interface could be accessed without deserialization or
> specialization.
>
> Consider:
> public interface FieldReadable {
> public object getValue(String field);
> }
>
> You could have an implementation that can getValue on PDX, POJO, JSON,
> BSON, XML, etc. There is no concern at this level with underlying storage
> type or the original unserialized form of the object (if any).
>
> -Jake
>
>
>
>
> On Tue, Jan 3, 2017 at 4:46 PM Dan Smith  wrote:
>
> > Hi Hitesh,
> >
> > There are a few different ways to store self describing data. One way
> might
> > be to just store the json string, or convert it to bson, and then enhance
> > the query engine to handle those formats. Another way might be extend PDX
> > to support self describing serialized values. We xould add a
> selfDescribing
> > boolean flag to RegionService.createPdxInstanceFactory. If that flag is
> > set, we will not register the PDX type in the type registry but instead
> > store it as part of the value. The JSONFormatter could set that flag to
> > true or expose it as an option.
> >
> > Storing self describing documents is a different approach than Udo's
> > original proposal. I do agree there is value in being able to store
> > consistently structured json documents the way we do now to save memory.
> I
> > think maybe I would be happier if the original proposal was more of an
> > external tool or wrapper focused on sanitizing json documents without
> being
> > concerned with type ids or a central registry service. I could picture
> just
> > having a single sanitize method that takes a json string and a standard
> > json
> > schema  and returns a cleaned up json document.
> > That seems like it would be a lot easier to implement and wouldn't
> require
> > the user to add typeIds to their json documents.
> >
> > I still feel like storing self describing values might serve more users.
> It
> > is probably more work than a simple sanitize method like above though.
> >
> > -Dan
> >
> >
> > On Tue, Jan 3, 2017 at 4:07 PM, Hitesh Khamesra
> >  > > wrote:
> >
> > > >>If we give people the option to store
> > > and query self describing values, then users with inconsistent json
> could
> > > just use that option and pay the extra storage cost.
> > > Dan, are you saying expose some interface to serialize/de and "query
> the
> > > some field in data - getFieldValue(fieldname)" dtata?  Some sort of
> > > ExternalSerializer with getFieldValue() capability.
> > >
> > >
> > >   From: Dan Smith 
> > >  To: dev@geode.apache.org
> > >  Sent: Wednesday, December 21, 2016 6:20 PM
> > >  Subject: Re: New proposal for type definitons
> > >
> > > I'm assuming the type ids here are a different set than the type ids
> used
> > > with regular PDX serialization so they won't conflict if the pdx
> registry
> > > assigns 1 to some class and a user puts @typeId: 1 in their json?
> > >
> > > I'm concerned that this won't really address the type explosion issue.
> > > Users that are able to go to the effort of adding these typeIds to all
> of
> > > their json are probably users that can produce consistently formatted
> > json
> > > in the first place. Users that have inconsistently formatted json are
> > > probably not going to want or be able to add these type ids.
> > >
> > > It might be better for us to pursue a way to store arbitrary documents
> > that
> > > are self describing. Our 

Re: Cluster Config

[William Markito Oliveira]

+1 -  Configuration should be consistent on the locators, specially cause
we should consider them source of truth for "distributed configuration"
anyway...

On Tue, Jan 3, 2017 at 1:59 PM, Swapnil Bawaskar 
wrote:

> I think we should not allow a mix of cc enabled or disabled across any
> member in the cluster (servers as well as locators)
> https://issues.apache.org/jira/browse/GEODE-1961.
>
> On Tue, Jan 3, 2017 at 11:25 AM, Jinmei Liao  wrote:
>
> > yeah, the reason we have issue2 is because of issue1, if we fix issue1,
> > then local changes are definitely more welcome than remote calls. The
> whole
> > idea of proposing change#2 is to get rid of some of the silliness of the
> > implementation. Change #2 would get rid of 4or 5 remote functions class
> at
> > least. The only change is that when user is connected to a locator
> without
> > CC, the command will get a output message saying "CC is not affected",
> but
> > we all know it's a rare case anyway.
> >
> > On Tue, Jan 3, 2017 at 10:41 AM, Jacob Barrett 
> > wrote:
> >
> > > If you fix issue 1 do you really need to change 2? I agree it is silly
> > that
> > > it remotes to another locator to execute the CC change but would it
> have
> > > any effect should all the locators be configured the same?
> > >
> > >
> > >
> > > On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao  wrote:
> > >
> > > > Ok, currently we have 2 issues:
> > > > 1) a cluster might have a mix of locators with and without CC
> enabled.
> > > The
> > > > change proposed is to reject locator that does not CC enabled to
> join a
> > > > locator that has CC enabled (or vise versa).
> > > > 2) commands that change CC does remote calls to a locator with CC to
> > > change
> > > > the cluster config. The change proposed is to simply do it on the
> > current
> > > > locator.
> > > >
> > > > Fix for issue 2 is NOT a workaround for issue 1, it's a step towards
> > > fixing
> > > > issue 1. No matter we fix issue 1 or not, change for issue 2 is
> needed.
> > > >
> > > >
> > > > On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett 
> > > > wrote:
> > > >
> > > > > I am not a fan of complicated work arounds for things like this.
> > Feels
> > > > like
> > > > > a lot of moving parts to address something that was more likely a
> > > > careless
> > > > > oversight than an intended use case. Why do you feel like we can't
> > > > address
> > > > > the underlying issue?
> > > > >
> > > > >
> > > > > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao 
> > wrote:
> > > > >
> > > > > > Currently our API or gfsh commands allow you to create a cluster
> > > with a
> > > > > mix
> > > > > > of locators with and without CC. Our DM maintains a list of
> > locators
> > > > and
> > > > > a
> > > > > > separate list of locators with CC enabled. It is bad, I know.
> But I
> > > am
> > > > > not
> > > > > > sure if we can change it.
> > > > > >
> > > > > > Assuming we have to live with cluster with mix of locators, would
> > my
> > > > > > proposal make sense?
> > > > > >
> > > > > > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer 
> > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > I think that the configurations of all locators should be
> > > identical,
> > > > or
> > > > > > at
> > > > > > > least in terms of a few "critical" properties. One would also
> > need
> > > to
> > > > > be
> > > > > > > able to amend some property changes at runtime, to allow for
> the
> > > > > changing
> > > > > > > of configuration without taking all the locators offline.
> > > > > > "remote-locators"
> > > > > > > would be a good candidate.
> > > > > > >
> > > > > > > --Udo
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 1/3/17 09:50, Jacob Barrett wrote:
> > > > > > >
> > > > > > >> If we consider the locators as the directory service for the
> > > cluster
> > > > > > then
> > > > > > >> it makes no sense for them to be configured differently. I
> think
> > > > > > locators
> > > > > > >> should be force to adopt the configuration of the other
> locator
> > in
> > > > the
> > > > > > >> cluster or refuse to join the cluster until their config is
> > > updated
> > > > to
> > > > > > >> match.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  >
> > > > wrote:
> > > > > > >>
> > > > > > >> Calling all the pros with knowledge on cluster configurations:
> > > > > > >>>
> > > > > > >>> This is regarding this current behavior of Cluster Config:
> > > > Assuming a
> > > > > > >>> cluster has 2 locators, locator-A-with-CC (with cluster
> config
> > > > > > enabled),
> > > > > > >>> and locator-B-without-CC (without cluster config enabled),
> > > > currently
> > > > > > any
> > > > > > >>> commands a user executes through Gfsh that affects cluster
> > config
> > > > > > (create
> > > > > > >>> region, deploy/undeploy 

Re: Assigning Jira tickets to new contributors

[William Markito Oliveira]

Great! So assigning people to the "contributors" role is good enough for
this, glad it worked!

On Sun, Dec 11, 2016 at 6:51 PM Kirk Lund <kl...@apache.org> wrote:

> Thanks William!
>
> On Sun, Dec 11, 2016 at 6:30 PM William Markito Oliveira <
> william.mark...@gmail.com> wrote:
>
> > I've just add all 3 (vectorijk, deepakddixit, dalyssakim) as
> "contributors"
> >
> > to the Geode JIRA project, but in the past we had problems with people
> not
> >
> > being able to "self-assign" JIRAs if they're not in the "committers"
> group.
> >
> >
> >
> > The workaround was to include them into the committers group on JIRA,
> which
> >
> > don't necessary give them commit privilege on the codebase, just on JIRA.
> >
> > Alternatively now that we graduated we could try fixing the role
> >
> > "contributor" of JIRA to at least allow people to assign JIRAs to
> >
> > themselves.
> >
> >
> >
> > Please give it a try now and see if you can assign the tickets to you,
> >
> > otherwise let us know.   Thanks!
> >
> >
> >
> > On Sun, Dec 11, 2016 at 5:35 AM, Kai Jiang <jiang...@gmail.com> wrote:
> >
> >
> >
> > > Hi Kirk,
> >
> > >
> >
> > > I am also a new contributor to GEODE project. Also, I am working on a
> few
> >
> > > issues(GEODE-2172 <https://issues.apache.org/jira/browse/GEODE-2172>
> >
> > > GEODE-2167 <https://issues.apache.org/jira/browse/GEODE-2167>
> GEODE-224
> >
> > > <https://issues.apache.org/jira/browse/GEODE-224>) . Maybe these issue
> >
> > > could be assigned to me.
> >
> > > Meanwhile, I will be appreciated if someone could review my pull
> > requests.
> >
> > >
> >
> > > JIRA id: vectorijk
> >
> > > Github id: vectorijk
> >
> > >
> >
> > > Thanks,
> >
> > > Kai.
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Sat, Dec 10, 2016 at 10:57 PM, Deepak Dixit <
> > deepakdixit2...@gmail.com>
> >
> > > wrote:
> >
> > >
> >
> > > > Hello Kirk,
> >
> > > >
> >
> > > > I remember some apache help document mentioning need for user to be
> > added
> >
> > > > to the project group.
> >
> > > > May be adding user to GEODE project group will help in enabling them
> to
> >
> > > > assign issues to themselves.
> >
> > > >
> >
> > > > Can you please grant similar permission to me (details are added
> below)
> >
> > > so
> >
> > > > I can assign JIRA issue I am working on?
> >
> > > > I am currently working on GEODE-2109 and just finished with
> GEODE-734.
> >
> > > >
> >
> > > > Detail for apache id
> >
> > > > Email ID: deepakdixit2...@gmail.com
> >
> > > > apache id: deepakddixit
> >
> > > >
> >
> > > > Thanks,
> >
> > > >
> >
> > > > Deepak
> >
> > > >
> >
> > > >
> >
> > > > On Dec 11, 2016 9:41 AM, "Kirk Lund" <kl...@apache.org> wrote:
> >
> > > >
> >
> > > > Does anyone know what needs to be done to enable assigning a Jira
> > ticket
> >
> > > to
> >
> > > > a new contributor? Alyssa Kim filed GEODE-2203 and would like to have
> > the
> >
> > > > ticket assigned to her but Jira shows either "No Matches" or "User
> >
> > > 'Alyssa
> >
> > > > Kim' does not exist." -- her user id on the Apache Jira is
> dalyssakim.
> >
> > > >
> >
> > > > Thanks,
> >
> > > > Kirk
> >
> > > >
> >
> > >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > ~/William
> >
> >
>

[jira] [Updated] (GEODE-2172) CustomConfigWithCacheIntegrationTest fails with AssertionError on Windows

[William Markito Oliveira (JIRA)]

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

William Markito Oliveira updated GEODE-2172:

Assignee: Kai Jiang

> CustomConfigWithCacheIntegrationTest fails with AssertionError on Windows
> -
>
> Key: GEODE-2172
> URL: https://issues.apache.org/jira/browse/GEODE-2172
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>Assignee: Kai Jiang
>  Labels: IntegrationTest, Windows
>
> cacheLogWriterMessageShouldMatchCustomConfig fails with AssertionError. See 
> attached file for full output from the test.



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

Re: TLP Transition Changes Coming

[William Markito Oliveira]

+1 as well - Although I'd say that in the near future we should consider
cleaning the list a little bit using some criteria...

For example, people on that list have NEVER sent a single message to the
mailing list, not to mention code contributions, wiki or anything so
why keep them ?

On Fri, Dec 2, 2016 at 12:02 PM, Dan Smith  wrote:

> >
> > As long as there are no objections, I will use the Committer list on the
> > Community product page (http://geode.apache.org/community/) to re-add
> > committers to the project.
> >
> >
> +1
>



-- 
~/William

Fwd: JSON License and Apache Projects

[William Markito Oliveira]

Interesting thread about json parsing libraries and licensing.  

Sent from my iPhone

Begin forwarded message:

> From: Ted Dunning 
> Date: November 24, 2016 at 2:28:47 PM PST
> To: "gene...@incubator.apache.org" 
> Subject: Re: JSON License and Apache Projects
> Reply-To: gene...@incubator.apache.org
> 
> Stephan,
> 
> What you suggest should work (if you add another dependency to provide the
> needed classes).
> 
> You have to be careful, however, because your consumers may expect to get
> the full json.org API.
> 
> I would suggest that exclusions like this should only be used while your
> direct dependency still has the dependency on json.org. When they fix it,
> you can drop the exclusion and all will be good.
> 
> 
> 
>> On Thu, Nov 24, 2016 at 2:21 AM, Stephan Ewen  wrote:
>> 
>> Just to be on the safe side:
>> 
>> If project X depends on another project Y that uses json.org (and thus
>> project X has json.org as a transitive dependency) is it sufficient to
>> exclude the transitive json.org dependency in the reference to project Y?
>> 
>> Something like that:
>> 
>> 
>>  org.apache.hive.hcatalog
>>  hcatalog-core
>>  0.12.0
>>  
>>
>>  org.json
>>  json
>>
>>  
>> 
>> 
>> Thanks,
>> Stephan
>> 
>> 
>> On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou 
>> wrote:
>> 
>>> is that library able to deal with the jdk9 module system?
>>> 
>>> 
 On 24.11.2016 02:16, James Bognar wrote:
 
 Shameless plug for Apache Juneau that has a cleanroom implementation of
>> a
 JSON serializer and parser in context of a common serialization API that
 includes a variety of serialization languages for POJOs.
 
 On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning 
 wrote:
 
 The VP Legal for Apache has determined that the JSON processing library
> from json.org  is not usable as
>> a
> dependency by Apache projects. This is because the license includes a
> line
> that places a field of use condition on downstream users in a way that
>> is
> not compatible with Apache's license.
> 
> This decision is, unfortunately, a change from the previous situation.
> While the current decision is correct, it would have been nice if we
>> had
> had this decision originally.
> 
> As such, some existing projects may be impacted because they assumed
>> that
> the json.org dependency was OK to use.
> 
> Incubator projects that are currently using the json.org library have
> several courses of action:
> 
> 1) just drop it. Some projects like Storm have demos that use twitter4j
> which incorporates the problematic code. These demos aren't core and
> could
> just be dropped for a time.
> 
> 2) help dependencies move away from problem code. I have sent a pull
> request to twitter4 j,
>> for
> example, that eliminates the problem. If they accept the pull, then all
> would be good for the projects that use twitter4j (and thus json.org)
> 
> 3) replace the json.org artifact with a compatible one that is open
> source.
> I have created and published an artifact based on clean-room Android
>> code
>  that replicates the most
> important
> parts of the json.org code. This code is compatible, but lacks some
> coverage. It also could lead to jar hell if used unjudiciously because
>> it
> uses the org.json package. Shading and exclusion in a pom might help.
>> Or
> not. Go with caution here.
> 
> 4) switch to safer alternatives such as Jackson. This requires code
> changes, but is probably a good thing to do. This option is the one
>> that
> is
> best in the long-term but is also the most expensive.
> 
> 
> -- Forwarded message --
> From: Jim Jagielski 
> Date: Wed, Nov 23, 2016 at 6:10 AM
> Subject: JSON License and Apache Projects
> To: ASF Board 
> 
> 
> (forwarded from legal-discuss@)
> 
> As some of you may know, recently the JSON License has been
> moved to Category X (https://www.apache.org/legal/resolved#category-x
>> ).
> 
> I understand that this has impacted some projects, especially
> those in the midst of doing a release. I also understand that
> up until now, really, there has been no real "outcry" over our
> usage of it, especially from end-users and other consumers of
> our projects which use it.
> 
> As compelling as that is, the fact is that the JSON license
> itself is not OSI approved and is therefore not, by definition,
> an "Open Source license" and, as such, cannot be considered as
> one which is acceptable as related to categories.
> 
>