name (subtype) -- the name for the particular instance
classpath -- the class of the particular instance
The type of the component will be able to be any String, but for standard components it will be preferable to use AgentComponentType entries.
This should be entirely backwards compatible to the older mechanism (one component per type).
There will be a difference between components for the same type. We have
the main component for the type (the first in the component list) -- can be retrieved by searching only for the type
auxiliary components for the type -- can be retrieved either as a list, or individually by specifying both type and name.
[ ] change AgentComponentName to AgentComponentType
[ ] at construction, the component will also send to the parent (will call the parent constructor with arguments) the name of the component, additional to its type.
[ ] getComponent(type) will return the main component for the type
[ ] getAllComponents(type) will return the entire list of components for the type.
[ ] getComponent(type, name) will return the specified auxiliary component for the type
[ ] in the scenario XML, a component C1 is able to have a <use type= subtype= > element specifying the component C2 that component C1 prefers to have as main component for the type.
[ ] in the scenario XML, there will be two ways of specifying components
the 'old' way, with the attribute name
the 'new' way, with the attributes type, name, classpath. The name should be optional for the main component (how to enforce this?).
both will also have an attribute classpath available.
[ ] an agent may add the same component instance to different types, in the two ways below. In both, the same classpath implies that the same instance, with the same component parameters, will be used.
the platform recommends the same classpath for both types, or
in the XML, the same classpath is entered for two different component types/names. Parameters will only be entered the first type the component element occurs, and a tag without nested parameter elements will be used for subsequent occurrences.
[ ] if the agent desires to load the same class, but as different instances for different type/subtypes, it will use the newInstance attribute for the component element.
[ ] in the agent, component types will be stored as Strings, but a warning is issued if an operation will specify the String value for the type of a standard component, instead of its AgentComponentType.
[ ] all standard components will have an associated interface that must be implemented by the loaded instance.
This is also related to issue #11.
Basically, a component will be identified by
The type of the component will be able to be any String, but for standard components it will be preferable to use AgentComponentType entries.
This should be entirely backwards compatible to the older mechanism (one component per type).
There will be a difference between components for the same type. We have
<use type= subtype= >element specifying the component C2 that component C1 prefers to have as main component for the type.nametype,name,classpath. The name should be optional for the main component (how to enforce this?).classpathavailable.newInstanceattribute for the component element.