Details
-
Bug
-
Status: Closed
-
High
-
Resolution: Fixed
-
None
-
Flagged
-
Pulsar
-
Pulsar 239 -DynamicComponents4, Pulsar 240 - 14.3 Hardening, Pulsar 241 - Site Dev APIs 1
Description
This is quite a severe architectural shortcoming in version 13. It can best be seen with the following example:
@ParametersInfo(
type = ValueListComponent.ValueListComponentInfo.class
)
public class ValueListComponent extends BaseHstComponent {
@Override
public void doBeforeRender(final HstRequest request, final HstResponse response) throws HstComponentException {
final ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
System.out.println(contextClassLoader);
}
public interface ValueListComponentInfo {
@Parameter(name = "foo", required = true, displayName = "Foo picker")
@DropDownList(valueListProvider = FooValueListProvider.class)
String getFirstFoo();
}
public static class FooValueListProvider implements ValueListProvider {
List<String> testList = Collections.singletonList("foo");
public FooValueListProvider() {
final HstRequestContext ctx = RequestContextProvider.get();
}
@Override
public List<String> getValues() {
return testList;
}
@Override
public String getDisplayValue(final String s) {
return "Foo";
}
@Override
public String getDisplayValue(final String s, final Locale locale) {
return "Foo";
}
}
}
The problem is that 'FooValueListProvider' always only is invoked from a Channel Manager interaction, which is a request to the /cms webapp. A ValueListProvider is only needed in CMS context, and never in site delivery context.
However, as can be seen above now, because of
@DropDownList(valueListProvider = FooValueListProvider.class)
the FooValueListProvider obviously needs to be present in the site webapp....but its usage is in the CMS webapp.
Hence the following should be done (which is not BC):
1) Move ValueListProvider from shared lib to CMS api
2) Support ValueListProvider implementation in CMS webapp and register them to, say, the HstComponentValueListProvider service which lives in the hippo registry
3) Wire DropDownList value provider to a custom value provider by name and not by class, for example
@DropDownList(valueListProvider = "foo-value-list-provider")
where the above does a lookup of the value list provider exposed via HstComponentValueListProvider service.
In ParametersInfoProcessor, when invoking
final List<String> valueList = valueListProvider.getValues();
we do not need to set the cms classloader on the current thread since it is already the cms classloader that loads the page composer classes and the current thread its classloader is already the cms classloader
