Broken: apache/geode-native#1991 (develop - b85c936)

[Travis CI]

Build Update for apache/geode-native
-

Build: #1991
Status: Broken

Duration: 10 mins and 26 secs
Commit: b85c936 (develop)
Author: Blake Bender
Message: GEODE-6914: Replace libxml with xerces-c in CacheXmlParser (#501)

- Replaced libxml references with Xerces.
- Removed dead code.
- Add xerces-c project back into dependencies.  This was pulled in 11/2017, but 
we're switching to using it in product code now
- Templatize function pointers using std::function
- Remove unused endPdx method
- Rename member variables to conform to our conventions
- Move getFactoryFunc into Utils where it belongs
- Added negative test case to verify we assert if missing required attribute
- GEODE-6914: Apply correct compiler settings to Xerces
- GEODE-6914: Disable schema validation for the time being
- Add alias for xerces-c to CMakeLists, update reference to it
- Mark Xerces headers as system headers
- Spell out 'function' in getFactoryFunction
- Corresponding formatting changes
- Add a CacheXmlParser test that loads a cache.xml with a bad schema and assert 
it doesn't throw, i.e. we're not validating schemas

Co-authored-by: Matthew Reddington 
Co-authored-by: Mike Martell 
Co-authored-by: Jacob Barrett 

View the changeset: 
https://github.com/apache/geode-native/compare/037a9ffdbeca...b85c9366ccb0

View the full build log and details: 
https://travis-ci.org/apache/geode-native/builds/556009578?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Juan José Ramos]

Done [1]!.
Please remember that, if no major concerns arise before Friday this week,
I'll go ahead and move the proposal to *Development* on July 13th.
Best regards.

[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-PriorArt

On Fri, Jul 5, 2019 at 3:48 PM Jacob Barrett  wrote:

> Can you please add a Prior Art section to your proposal discussing these
> alternative solutions and why they are insufficient?
>
> Thanks,
> Jake
>
>
> > On Jul 5, 2019, at 10:41 AM, Juan José Ramos  wrote:
> >
> > Hello Jake,
> >
> > I've replied something similar *here [1]*.
> > Long story short, I haven't found anything that really applies to our use
> > case. The "most similar solution" is *Spring Method Security [2]*, which
> > basically implies annotating methods with explicit configuration about
> the
> > roles required to execute them. The same goes for *Shiro
> **Annotation-based
> > Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
> > from the proposal is somewhat similar to this, but I've discarded it
> > because if forces the user to annotate classes with our own annotations,
> > basically forcing them to modify their domain model.
> > The proposal basically allows our users to use one of the default of the
> > box implementations and, if they don't like them for whatever reason, is
> > flexible enough so they can ultimately provide their own.
> > Hope this helps.
> > Cheers.
> >
> > [1]:
> >
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> > [2]:
> >
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> > [3]:
> >
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> > [4]:
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
> >
> > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett 
> wrote:
> >
> >> So if we don’t want to use the Java built in SecurityManager to solve
> >> this, because we feel it's too big or too inflexible for our needs, have
> >> other projects implemented something we can borrow? We can’t be the
> first
> >> to need something like this if Java’s solution isn’t a good fit.
> >>
> >> Again I want to avoid inventing something new. What prior art is out
> there?
> >>
> >>
> >>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos  wrote:
> >>>
> >>> Hello all,
> >>>
> >>> If you haven't added my email to the spam folder already :-), then I'd
> >> like
> >>> to let you know that I've update again the *Proposal [1]* and
> >> incorporated
> >>> most of the feedback provided, along with some additional information
> and
> >>> context I missed on the previous versions, thanks all that brought
> >> concerns
> >>> and suggestions to the discussion. Please take some time to review it
> >>> thoroughly, adding comments and/or concerns *only on this email
> thread*,
> >>> all feedback is more than welcome.
> >>> If no major concerns arise before July 12th 2019, I'll go ahead and
> mark
> >>> move the proposal to *Development* on July 13th.
> >>> Best regards.
> >>>
> >>> [1]:
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> >>
> >>
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jra...@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support]  [image: twitter]
> >  [image: linkedin]
> >  [image: facebook]
> >  [image: google plus]
> >  [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>
>

-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Gateway-sender alert-threshold function not working for gateway sender

[Mario Ivanac]

Hi, according to implementation, events which exceed alert threshold are 
reported only for AsyncEventQueue,

but not for GatewaySender 
(https://issues.apache.org/jira/browse/GEODE-6933).


Is there any reason for this behavior?