Hi, first of all, I'm wondering if your approach is really a good one. Wouldn't it be easier/more sensible if the agent either ignores further messages after the first one or return an error to the TestV3EnvironmentActionAgent1? If the service is removed, it may be difficult for the TestV3EnvironmentActionAgent1 to determine if the call did not succeed because the service was intentionally removed or e.g. connectivity was lost. Regardless, in the code you provided: IServiceIdentifier sid3 = ((IService)agent.getProvidedService(INotifyService1.class)).getServiceId();...
Hi! Sure, you can dynamically add and remove services at any time in the respective agent, e.g. inject internal access first: @Agent protected IInternalAccess agent; Then use one of the addService() or removeService() methods anywhere in the agent (instead of @ProvidedService): agent.addService("chatservices", new ChatServiceF1()); This also automatically updates the service registry infrastructure as needed in the background. However, given your description, I suspect there could be better solutions....
Hi Kevin, sorry I was only able to have a cursory look at your sourced but apparently you are using the getAvatars()-Method to check if the avatar was created. Generally there are two ways how the environment auto-creates avatars: The environment notices the new component or the component accesses its avatar through the getAvatar() (singular, not getAvatars()) method. The environment ensures there is only one avatar created. There is a bit of asynchronous behavior between the environment and agent...
Hi, your assumption is correct, in fact, this is the default so it ought to work: https://github.com/actoron/jadex/blob/96079a9f50f08f256bf22b136c70b12bb10eda6e/docs/guides/env/04%20Component%20Interaction.md Could you please provide a minimal example project so we can look into it? Kai
Yes, this is an alternative way which adds task during initialization. Unfortunately, I do not think we have an example of this, but basically you can add tasks to <env:object></env:object> in the <configuration></configuration> section by including lines like <env:task type="move_train"></env:task>. In general, be aware that EnvSupport is an older part of the Jadex codebase, hence the quirky API. If this does not bother you, you are, of course, free to use it. Edit: The .application.xml has an XML-Schema,...
Yes, this is an alternative way which adds task during initialization. Unfortunately, I do not think we have an example of this, but basically you can add tasks to <env:object></env:object> in the <configuration></configuration> section by including lines like <env:task type="move_train"></env:task>. In general, be aware that EnvSupport is an older part of the Jadex codebase, hence the quirky API. If this does not bother you, you are, of course, free to use it. Kai
Hi, your application.xml, which only defines the task type. The avatar/object has to actually instantiate the task using the IEnvironmentSpace.createObjectTask() method for the give space object (identified by objectid). Kai
Hi Kevin, thank you for trying Jadex. We are currently in a bit of a transition, so things may appear a bit confusing. Yes, our download page currently show version 3 of Jadex as the current one, however, we often recommend version 4 of Jadex, with the biggest remaining item being updated documentation for version 4. Version 3 is, unfortunately, not compatible with Java 11, however, version 4 should be working. Could you please elaborate on the problem you had using the combination of Jadex 4 and...