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.
IME, this has been due to class conflicts and library load order.
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.
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.