Questions & Answers

[ADR81SGP]

Dear FirstSpirit Community,

we have an issue in an FSM script where the attached error occurs when executing on the server in a project in schedule entries.
Before the isolated-mode migration of the server it worked perfectly fine. No logical code changes happend in between.

The first few lines of the script are executed as I see a log message indicating the same, but after that, I get that error as attached. On what line the error is thrown, I am not sure of.

Have you experienced this kind of error and can give a hint where it may occur?
Are any code changes necessary for isolated-mode except module-isolated.xml and pom.xml?

Java version: 11
FirstSpirit version: 2020-05

I kindly ask for some insights from your end. Thank you!

[felix_reinhold]

Hi Eric,

code changes are necessary if you've used Methods and classes that are for internal use only. It's hard to help without the script but in this case:

Did you set the "All permissions" checkbox after updating the module? It looks like an exception when accessing the filesystem (which requires this flag).

Best regards

Felix

[ADR81SGP]

Hi Felix,

I was afraid you would say something like that.

I checked the "All Permissions" checkbox and it indeed is set. I also use a custom connection in the ScriptTask.

Anyhow, I executed it again now and I get a different error as attached.

[felix_reinhold]

Hi Eric,

since the error relates to the berkeley db you could ask the helpdesk for support. Maybe it's just a corrupt section which could be fixed with the repository viewer - but in this case the problem should already occur in legacy mode. I only know this exception if the java security policy isn't set correctly, but that doesn't relate to the isolated mode as well.

I guess the HelpDesk is your best option here.

To quickly check if a specific section is the problem you could add log output to:

com.bosch.firstspirit.settings.replacer.DataProviderMaps.lambda$getDeclaredVariablesMap$1(DataProviderMaps.java:25)

Just log the section and skip the section that is logged when the error occurs

.

Best regards

Felix

[ADR81SGP]

Hi Felix,

wow, now I feel like a dope, I did not see that! Let's pick it up from there. The method is as following:

@NotNull static Map<String, DataProvider> getDeclaredVariablesMap(@NotNull List<DataProvider> dataProviders) {
        final Map<String, DataProvider> map = new HashMap<>();
        dataProviders.parallelStream().forEach(dataProvider -> {
            final FormData formData = dataProvider.getFormData();
            final List<GomFormElement> gomFormElements = new ArrayList<>();
            formData.getForm().forms().forEach(gomFormElements::add);
            gomFormElements.forEach(gomFormElement -> map.put(String.valueOf(gomFormElement.getName()), dataProvider));
        });
        //map.forEach((variableName, dataProvider) -> logDebug("\"" + variableName + "\"", Logger.class));
        return map;
    }

Could the issue be here in some method call inside the method? By the logs, I would say it is between line 4 and 11.

[felix_reinhold]

Hi Eric,

it's this line:

final FormData formData = dataProvider.getFormData(); 

Before that line you could add a log output (or of course use remote debugging) to get the id of the dataProvider that is creating the error.

Best case: There's just one corrupt page/section that can be fixed via RepositoryViewer.

If not then you seem to have issues with your berkeley db. In both cases you should ask the e-Spirit Helpdesk for support (if you don't have any experience in using the RepositoryViewer).

Best regards

Felix

[ADR81SGP]

Hi Felix,

awesome, I looked for the ID of the data provider causing the problem and we just found the issue or rather the source of the issue. In line 5 we try to get the form data of a page where a FS_CATALOG is placed. Then the exception occurs.

What does that tell us though? I know for a fact that I can call getFormData() on any page.

[felix_reinhold]

Hi Eric, have you tested, if the issue still persist, if you skip that page?

But nevertheless you should open a helpdesk ticket for that issue.

[ADR81SGP]

Hi Felix,

sorry for my rather short answer before. The issue does not persist when removing the FS_CATALOG from the template of that aforementioned issue-causing page. So I need to do some digging why this FS_CATALOG is causing the exception of "cannot load section."

Yeah well, to say the least: the helpdesk told me to come here to the community and address the issue in the first place. They told me: "since this is an issue with an implementation and no product problem I have to forward you to our Professional Service or our community."

Or do you think now it is not an implementation problem any longer?

[felix_reinhold]

Hi Eric,

if you keep the FS_CATALOG in the template can you reproduce the error by calling getFormData on the page from Beanshell Console?

I'm still trying to figure out the conneciton between the isolated mode and this change.

I thought that maybe one or more of the embedded contents in the FS_CATALOG are using templates with custom inputcomponents, DataAccessPlugins, Hotspots or stuff like that that can be affected by the isolated mode.

Maybe we should just do a short websession - that might be faster :smileygrin:

You can write me an email to fr@accitio.com to find a timeslot