public interface ActorOrientedClassProvider
These providers could obtain such assemblies from moml class definitions in files, databases or other storage systems, or defined in any relevant manner.
Implementations should typically be injected in a ClassLoadingStrategy. Currently the OSGiClassLoadingStrategy is the main injection target.
Modifier and Type | Method and Description |
---|---|
CompositeEntity |
getActorOrientedClass(java.lang.String className,
VersionSpecification versionSpec)
Returns the
CompositeEntity providing the requested actor-oriented class definition, if this provider has it. |
CompositeEntity getActorOrientedClass(java.lang.String className, VersionSpecification versionSpec) throws java.lang.ClassNotFoundException
CompositeEntity
providing the requested actor-oriented class definition, if this provider has it.
An actor-oriented class can have only a "simple" name, i.e. no dots, as the underlying NamedObj
does not allow dot-separated names.
However, provider implementations may allow className
values with dots.
Remark that once loaded in the Ptolemy runtime, all actor-oriented classes are managed by their "simple" name only!
So, when using dot-separated "nested" names, the final part must still be unique within the complete runtime!
So using hierarchical class names may make sense to support organizing the classes in hierarchical structures for storage and lookup, instead of being limited to simple "linear" lists. But they do not introduce a runtime "name space" like packages do for Java classes.
If this provider doesn't have this class available, it should throw aClassNotFoundException
.
(Optionally, it could also just return null, for those dvp-ers who don't like exceptions. ;-) )className
- Mandatory, not-null.versionSpec
- optional constraint on desired version for the class that must be provided. If null, no version constraint is imposed.java.lang.ClassNotFoundException
- if this provider can not provide the requested class for the requested version (if specified)