Description
I think I hit a bug in HST-2 Content Beans API. (in 7.9.8.).
It can be reproduced like the following:
0. Suppose you have a [news] document which has mirror links to [category] documents.
1. Run the following:
News news = (News) objectConverter.getObject(node);
for (HippoBean cat :
news.getLinkedBeans("ns1:category", HippoBean.class))
, which print out OK if the mirror link document is available.
- /content/documents/ns1/news/test-news-category/category1/category1
- /content/documents/ns1/news/test-news-category/category2/category2
2. Now take offline a [category] document and delete the document in CMS UI, which results in the mirror link UUID is pointing to the hippo:deleted node in attic folder!
3. Now run the code again. Then it returns linked bean(s) in the same size still and one linked bean prints out the attic node link!
- /content/attic/b/9/0/3/category1/category1
- /content/documents/ns1/news/test-news-category/category2/category2
hippo:deleted primary type in attic node is a subtype of hippo:document, so HST-2 Content Beans API creates a HippoDocument as a result.
I think this is an obvious bug.
I know maybe if I use different class type in #getLinkedBeans() call, it might filter out this fallback, but still it is broken because it's returning a valid bean from a deleted attic node.
Also, please note that Hippo Essentials generates beans returning HippoBean type at the moment, instead of specific type beans, for linked beans getter method. That's another issue because I don't think HST-2 Content Beans can return a non-null object for a deleted node in #getLinkedBeans() call.