Adding the priority is fine as a fallback plan (like it will work). But it is more a band-aid than a cure. It just puts off the problem (two accessors can have the same number and we are right back to chance).
Some questions: Q: Is there anyway to tighten up the reporting so that FeaturePropertyAccessor does not respond? It is much nicer to have an API that requires unambiguity - only add accessors when you add new kinds of data to query. Q: Why do you need a custom property accessory? If both FeaturePropertyAccessor and your customer property access can do the job… If it is for performance then just adding priority will not be so good, it is better to do something like the sorting and enable/disable that was done for the icon factories (which are very performance sensitive). I expect it was done with pairwise ordering which is another common pattern in GeoTools code… I am curious what your property accessor does! -- Jody Garnett On Mon, Jul 22, 2024 at 3:53 PM Nuno Oliveira < nuno.olive...@geosolutionsgroup.com> wrote: > Hi, > > I've encountered an issue where a custom property accessor suddenly > stopped working. Upon investigation, I found that the problem originates > from the fact that the order in which property accessors are read and > registered is random and lacks an explicit priority mechanism. This is > usually not problematic because most property accessors will simply > indicate that they cannot handle the provided property path. However, in my > case, the permissive FeaturePropertyAccessor > <https://github.com/geotools/geotools/blob/f02e34f8fce93e7620a319ef1fd9daab8ba5c67d/modules/extension/complex/src/main/java/org/geotools/data/complex/expression/FeaturePropertyAccessorFactory.java#L209> > happens to be loaded as one of the first properties accessor, taking > precedence over my custom property accessor. > > GeoTools allows extensions to register property accessors, which are > loaded HERE > <https://github.com/geotools/geotools/blob/1b4c81fc632b4c0a106593a957925f57861e5a9d/modules/library/main/src/main/java/org/geotools/filter/expression/PropertyAccessors.java#L32-L50>. > As you may know, a property accessor defines how a provided property path > (for example in a filter) should be interpreted when applied to a feature. > GeoTools uses the first property accessor capable of retrieving the > property value, this happens HERE > <https://github.com/geotools/geotools/blob/1b4c81fc632b4c0a106593a957925f57861e5a9d/modules/library/main/src/main/java/org/geotools/filter/expression/PropertyAccessors.java#L55-L81> > . > > To address this issue, I propose introducing a prioritization concept for > property accessors. This would allow extensions to register property > accessors with specific priorities, ensuring that they are evaluated before > default permissive ones, regardless of the loading order. What I have in > mind is the following: > > 1. > > Introduce priority constants: > - > > HIGHEST_PRIORITY (0): For the most preferred property accessors. > - > > DEFAULT_PRIORITY (3000): For the standard priority level. > - > > LOWEST_PRIORITY (5000): For the least preferred property accessors. > 2. > > Update the PropertyAccessorFactory interface: > - > > Add a getPriority() method to the PropertyAccessorFactory interface > that returns the priority of the property accessor as an integer. By > default, this method should return DEFAULT_PRIORITY, but > implementations can override it to provide custom priority values. > 3. > > Modify FeaturePropertyAccessorFactory: > - > > Adjust this class to return LOWEST_PRIORITY in its getPriority() > method. This change indicates that this accessor is the most generic and > should be used only when no higher-priority accessors are applicable. > 4. > > Sort Property Accessors: > - > > Implement sorting of property accessors in the PropertyAccessors > class based on their priority. This ensures that accessors with higher > priorities are processed before those with lower priorities. > > This prioritization mechanism will allow for more controlled and > predictable behavior when working with custom property accessors in > GeoTools. > > Any comments? > Looking forward to reading your feedback, > Nuno Oliveira > > -- > > Regards, > > Nuno Oliveira > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Nuno Miguel Carvalho Oliveira > @nmcoliveira > Technical Lead / Project Manager > > > GeoSolutions Group > phone: +39 0584 962313 > fax: +39 0584 1660272 > > https://www.geosolutionsgroup.com/ > http://twitter.com/geosolutions_it > ------------------------------------------------------- > > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail. > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
