Questions & Answers

[Aradhana]

Hi Team,

In my module i have 9 internal espirit classess (NON_API_USAGE) and one Dependency on class not available in isolated mode ,so my questions is ,is there any alternative jars we need to use in our module or do we need to re write all the internal espirit classes in our own code base.currently we are using fs-isolated-runtime jar only in our module.

Thanks in advance!!

Regards,

Aradhana

[Windmüller]

Dependencies marked as "NON_API_USAGE" are not part of the stable API and may change anytime without notice. In order to ensure that your module works with future FirstSpirit versions, we recommend to minimize those dependencies and use the official API.

Can you please elaborate which class has been reported as "not available in isolated mode"?

[Aradhana]

Hi,

Can you provide the details like which  official API we need to use if we remove NON_API_USAGE dependency like what will be the replacement of NON_API_USAGE from where we can get the all details.

Below are the NON_API_USAGE dependencies from one module:

de.espirit.firstspirit.access.editor.value.SimpleOption
de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormData
de.espirit.firstspirit.server.storemanagement.exception.ElementNotFoundException
de.espirit.storage.File
de.espirit.storage.Type

Below class not available in isolated mode:

de.espirit.firstspirit.io.servlet.WebCallback 

[Windmüller]

Unfortunately there is no 1:1 mapping between API and non-API classes. The replacement procedure depends on what you want to achieve with your code. Without any knowledge of your code I am unable to provide any advice.

As a general rule, try to use only those classes listed in the API documentation. If a use-case is not covered there, please open a support ticket so we can discuss an extension of the API for future versions of FirstSpirit.

[mbergmann]

Is there a reason WHY you use those non API classes instead of those in the API? I‘ve come across cases where developers used internal classes just because they used .getClass() somewhere to find out which type is returned - and then just used that one. And not because they really need to use that class.

What I mean is: A first approach would be to check if you can also use (at least in some places) an interface from the API that is implemented by the internal class you are currently using. Just as an example: Option instead of SimpleOption, FormData instead of EntityFormData. If that’s possible in your case depends - as Stephan mentioned - on your code.