as IData is a very basic central class of IS, which also used internally, it should be available by default.
Can you share the About page of your IS Admin UI with the classpath section, please?
Additionally, please provide the server.log snippet, where the packages are loaded and activated (started up), including the line you have mentioned above.
@RCA , Iāve asked before but Iāll ask again: is this occurring in a local development environment or a regular environment?
Have you tried moving the package to a different Integration Server to see if the same behavior occurs there? You could even just pull down a Docker image from the Software AG Container Registry to try against.
If the same behavior occurs there (and that behavior is not observed with other packages on that other server), then itās likely an issue with the package itself (e.g. a startup service doing something unusual, inappropriate class loader settings in your manifest.v3 file, etc).
If the same behavior does NOT occur on the new IS, then itās likely an issue with the Integration Server itself (e.g. settings that were changed, a missing fix, or perhaps a bad patch).
As Iāve suggested before (and so have others), feel free to share your package. We could load it on our Integration Servers to help attempt to replicate the issue for you. If I were you, Iād also open a ticket with Software AG to attack the issue on multiple fronts.
There is nothing obviously wrong with the code. But itās not possible to debug further without actually have the entire package. IData belongs to com.wm.data package which you have in your imports. Unless you deleted the wm-isclient.jar file somehow, this should not happen.
@Percio_Castro1
Yes, I have conducted the tests, and the package works perfectly in another environment. The issue is only present on my local instance.
I think the easiest solution is to reinstall a new localhost instance.
@Holger_von_Thomsen
I cannot share the server.log because it contains confidential information.
@RCA , I agree. Sounds like something was inadvertently changed in your local installation and the easiest solution would be to reinstall. When reinstalling and reconfiguring the local IS, perform one step at a time and verify the issue hasnāt returned along the way. This way, if the issue does return, you can easily pinpoint which step of the installation/configuration caused it. Please do share if you ever find the root cause.
I did not ask for the complete server.log but just the startup sequence, esp. package loading and starting order along with corresponding error messages.
Beside package names, host names, IP-adresses and ports this part should not contain confidential life data as the issue seems to occure before the startup sequence is completed (āThe IntegrationServer startup was completed in xxx secondsā and āConfigFile directory savedā should be the last messages from this sequence).
The previously mentioned informations can be masked as long as the structure can be identified where the issue arises from.
Rename and recreate the server.log file when performing the next shutdown and start sequence, not restart only.