spring-projects / spring-data-geode

Spring Data support for Apache Geode
Apache License 2.0
50 stars 37 forks source link

<gfe:entry-ttl> and <gfe:entry-tti>elements are not allowed under <gfe:replicated-region> #616

Closed sjoshid closed 1 year ago

sjoshid commented 1 year ago

Im using Apache Geode 1.14.4 and spring-data-geode version 2.7.2. I have following region config which fails to bring up my app.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:gfe="http://www.springframework.org/schema/geode"
       xsi:schemaLocation="http://www.springframework.org/schema/geode http://www.springframework.org/schema/geode/spring-geode.xsd">
    <gfe:replicated-region id="regionId" cache-ref="myCacheRef">
        <!-- When region.get(k) is a cache-miss, this loader will be called to load the value (eg. from db) -->
        <gfe:cache-loader ref="myLoader"/>
        <gfe:cache-writer ref="myWriter"/>
        <!-- Time-to-live (TTL) is used for creation and put operations -->
        <gfe:entry-ttl timeout="300" action="DESTROY"/>
        <!-- Idle timeout (TTI) is used for get and netSearch operations -->
        <gfe:entry-tti timeout="300" action="DESTROY"/>
    </gfe:replicated-region>
</beans>

The exact error is: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 29 in XML document from file [C:\Users\sjoshi\context\geode-context.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 29; columnNumber: 56; cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://www.springframework.org/schema/geode":entry-ttl}'. One of '{"http://www.springframework.org/schema/geode":membership-attributes, "http://www.springframework.org/schema/geode":gateway-sender, "http://www.springframework.org/schema/geode":gateway-sender-ref, "http://www.springframework.org/schema/geode":async-event-queue, "http://www.springframework.org/schema/geode":async-event-queue-ref, "http://www.springframework.org/schema/geode":subscription, "http://www.springframework.org/schema/geode":eviction, "http://www.springframework.org/schema/geode":lookup-region, "http://www.springframework.org/schema/geode":replicated-region, "http://www.springframework.org/schema/geode":partitioned-region, "http://www.springframework.org/schema/geode":local-region, "http://www.springframework.org/schema/geode":client-region}' is expected.

jxblum commented 1 year ago

Your SDG XML configuration metadata (above) is not correctly defined (formed) according to the SDG XSD (see here).

Specifically, the ordering of the CacheLoader/Writer configuration elements (i.e. <gfe:cache-loader> and <gfe:cache-writer>) inside the Replicated Region (<gfe:replicated-region>) element is not correct.

It should be defined as:

<beans xmlns="http://www.springframework.org/schema/beans"
              xmlns:gfe="http://www.springframework.org/schema/geode"
              xsi:schemaLocation="http://www.springframework.org/schema/geode 
                  http://www.springframework.org/schema/geode/spring-geode.xsd">

    <gfe:replicated-region id="regionId" cache-ref="myCacheRef">
        <gfe:entry-ttl timeout="300" action="DESTROY"/>
        <gfe:entry-tti timeout="300" action="DESTROY"/>
        <gfe:cache-loader ref="myLoader"/>
        <gfe:cache-writer ref="myWriter"/>
    </gfe:replicated-region>
</beans>
sjoshid commented 1 year ago

I had no clue entries need to be ordered 🤯

jxblum commented 1 year ago

I was able to reproduce your outcome using the SDG RegionExpirationAttributesNamespaceIntegrationTests class (see here) with its associated XML configuration file (see here). You can see the changes that I made in this commit.

Specifically, I defined CacheListener, CacheLoader and CacheWriter configuration elements for the Replicated Region, here. This works as expected and the test passes!

jxblum commented 1 year ago

In general, the ordering of elements defined by the SDG XSD has existed for as long as SD Geode has been project. While some of the restrictions defined in the SDG XSD may be possible to lift, changing the XSD even a slight bit, could potentially and adversely affect other users' existing configuration metadata.

So, we don't generally make many changes to the XSD, such as re-ordering of the elements, changing type definitions, or otherwise, in any significant way.

Also, among many others reasons, this is also 1 reason why Spring overall has gravitated away from XML configuration metadata in favor of JavaConfig... Type-Safety and flexibility.

SDG has comprehensive support for Annotation-based (see here) as well as Java-based configuration metadata (see the API).

On top of that Spring Boot for Apache Geode (SBDG) makes this even easier with Spring Boot's auto-configuration, convention over configuration approach. See project page here, and documentation here (Ref Doc) and here (Javadoc).

A really good way to get started is by looking at the Samples, and specifically, the Getting Started sample.

Spring Boot is the way.

I recommend moving away from XML configuration.

sjoshid commented 1 year ago

That all makes sense. I honestly didnt even know ordering can be mandated by an xsd like that. I would like to switch to Spring Boot. One day...