The interface includes the getProperty() and getPropertyNames() methods familiar from the RenderedImage and RenderableImage interfaces. Classes which implement this interface should do so in a manner which treats the property names as case-retentive. That is to say that as concerns operations effected using the property name as a key, the operation should ignore the case of the property name while on the other hand the property name retrieval methods should return the names with their case preserved.
PropertySource is implemented by the ImageJAI interface and, among other classes, by PlanarImage, RenderableOp and CollectionImage. Since all RenderedImages used with JAI are "wrapped" by a RenderedImageAdapter, all JAI RenderedImages may be assumed to implement PropertySource.
If a PropertySource is also a PropertyChangeEmitter then it should fire PropertySourceChangeEvents to all registered listeners whenever this is reasonable to do so in the context of the PropertySource in question.
Property name space collisions may be prevented by adhering to an hierarchical naming convention. This could for example be based on the name of the package in question, e.g., com.lightcrafts.media.jai.MyProperty. The names of properties generated by JAI itself will not adhere to the aforementioned naming convention, but this should not pose a problem if users adopt this convention for their own property names.
Another approach to handling multiple property name spaces would be to define a separate PropertySource for each name space of properties. These PropertySources could themselves be attached to images as properties. Inheritance of these properties would occur by the default mechanism. Modification of these properties within an operation chain could be managed by PropertyGenerators which are capable of recognizing these properties. Note that a potential problem with this approach exists when a PropertySourceChangeEvent is fired: it might be necessary to clone the entire tree of properties in order to obtain the old value of event object.
@see ImageJAI
@see PlanarImage
@see PropertyChangeEmitter
@see WritablePropertySource
@see java.awt.image.RenderedImage
@see java.awt.image.renderable.RenderableImage
The interface includes the getProperty() and getPropertyNames() methods familiar from the RenderedImage and RenderableImage interfaces. Classes which implement this interface should do so in a manner which treats the property names as case-retentive. That is to say that as concerns operations effected using the property name as a key, the operation should ignore the case of the property name while on the other hand the property name retrieval methods should return the names with their case preserved.
PropertySource is implemented by the ImageJAI interface and, among other classes, by PlanarImage, RenderableOp and CollectionImage. Since all RenderedImages used with JAI are "wrapped" by a RenderedImageAdapter, all JAI RenderedImages may be assumed to implement PropertySource.
If a PropertySource is also a PropertyChangeEmitter then it should fire PropertySourceChangeEvents to all registered listeners whenever this is reasonable to do so in the context of the PropertySource in question.
Property name space collisions may be prevented by adhering to an hierarchical naming convention. This could for example be based on the name of the package in question, e.g., com.sun.media.jai.MyProperty. The names of properties generated by JAI itself will not adhere to the aforementioned naming convention, but this should not pose a problem if users adopt this convention for their own property names.
Another approach to handling multiple property name spaces would be to define a separate PropertySource for each name space of properties. These PropertySources could themselves be attached to images as properties. Inheritance of these properties would occur by the default mechanism. Modification of these properties within an operation chain could be managed by PropertyGenerators which are capable of recognizing these properties. Note that a potential problem with this approach exists when a PropertySourceChangeEvent is fired: it might be necessary to clone the entire tree of properties in order to obtain the old value of event object.
@see ImageJAI
@see PlanarImage
@see PropertyChangeEmitter
@see WritablePropertySource
@see java.awt.image.RenderedImage
@see java.awt.image.renderable.RenderableImage
{@code PropertySource} objects are not typically used in isolation, but ratherthrough a {@link PropertySources} object, which aggregates property sources and inconjunction with a {@link PropertyResolver} implementation that can performprecedence-based searches across the set of {@code PropertySources}.
{@code PropertySource} identity is determined not based on the content ofencapsulated properties, but rather based on the {@link #getName() name} of the{@code PropertySource} alone. This is useful for manipulating {@code PropertySource}objects when in collection contexts. See operations in {@link MutablePropertySources}as well as the {@link #named(String)} and {@link #toString()} methods for details.
Note that when working with @ {@link org.springframework.context.annotation.Configuration Configuration} classes thatthe @ {@link org.springframework.context.annotation.PropertySource PropertySource}annotation provides a convenient and declarative way of adding property sources to the enclosing {@code Environment}. @author Chris Beams @since 3.1 @see PropertySources @see PropertyResolver @see PropertySourcesPropertyResolver @see MutablePropertySources @see org.springframework.context.annotation.PropertySource
| |