[MAGNOLIA-8345] Decorating searchResultSuppliers does not work as expected. Created: 14/Mar/22  Updated: 15/Mar/22

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Rico Jansen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled

 Description   

Because of MAGNOLIA-8343 I have decorated the pages and dam apps to use our own searchresultsupplier. However I run into some issues with that.

Using our own definition caused a strange error in the logs:

java.lang.IllegalArgumentException: object is not an instance of declaring class

caused by

nl.vpro.magnolia.periscope.JcrSearchResultSupplierDefinition$ByteBuddy$5BDXAzX5.getSubAppName(Unknown Source) ~[?:?]

Investigation showed that somehow the that the definition is of the type info.magnolia.periscope.search.jcr.JcrSearchResultSupplierDefinition and not the interface info.magnolia.periscope.search.SearchResultSupplierDefinition so calls passed through fail since our version does not extend from that it fails.

First workaround attempt was to extend from info.magnolia.periscope.search.jcr.JcrSearchResultSupplierDefinition however that is not possible since it returns not the interface but a instance of JcrSearchResultSupplierStrategy and if you try to extend from that as well, you land in a rabbithole of package protected and private methods.

Final workaround was to fully copy the searchresultsupplier definition and fill in all null values with actual values as to avoid calls to the original definition.

 



 Comments   
Comment by Rico Jansen [ 15/Mar/22 ]

Regarding the instance/interface issue, it might be expected as the method name is the same although the classes are different. So that might be an issue at our end.

Generated at Mon Feb 12 04:31:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.