Closed sjoshid closed 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>
I had no clue entries need to be ordered 🤯
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!
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.
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...
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.
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.