[JCRVLT-517] FSPackageRegistry.contains does not initialize packages

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 3.4.10
• Fix Version/s: 3.5.0
• Assignee: Konrad Windszus
• Reporter: Hans-Peter Stoerr
• Created: 27/Apr/21 16:01
• Updated: 17/Dec/21 13:07
• Resolved: 05/May/21 06:39

Description

The implementation of FSPackageRegistry.contains in the current implementation line 249  does just `return stateCache.containsKey(id);` without initializing the stateCache, as e.g. the method packages() (line 640) does. I strongly suggest that it should initialize the stateCache (that is, call loadPackageCache() ) if it wasn't initialized before returning.

I stumbled over this because I'm using the Sling Feature Launcher and apply to org.apache.sling.jcr.packageinit triggered by org.apache.sling.extension.content to deploy content packages from the feature launcher, and this always fails since it says the packages aren't found. The reason for this is that org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate gets called, which uses FSPackageRegistry.contains, and this fails since the FSPackageRegistry isn't initialized yet.

There is a workaround for this FSPackageRegistry problem by inserting a FSPackageRegistry.packages() call into ExecutionPlanRepoinitializer to initialize the FSPackageRegistry and throwing away the result, but I don't think this is the right way to solve this problem.  So I'm reporting this as a bug in org.apache.jackrabbit.vault .
Thank you!

Issue Links

• causes: JCRVLT-575 do not fail if home path for package registry contains a symlink
• is related to: SLING-10339 Execution plan failure for JCR Package Init
• links to: GitHub Pull Request #135
• links to: GitHub Pull Request #136