[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 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. |