VWP packages a number of property editors together in a module. The editors have
been used in the past by other, third-party component developers, who were given
the module JAR so that they could compile design-time code that is intended for
use with VWP. This gives rise to a number of issues:

    * We need a means of refactoring all classes in the property editors module
(changing "com.sun.rave" to "org.netbeans.visualweb"), while still allowing
extant third-party component libraries to function correctly in VWP.

    * Ideally, we also need a better means of making property editors available
to third-party component developers. The current editors have dependencies on
modules in org.openide, and it is generally not appropriate to treat a NB module
as though it were a third-party library.

To resolve these issues, it is proposed to split the property editors module
into a library of property editor interfaces, and a module of property editor
implementations. VWP will guarantee to always provide an implementation
appropriate for each of the interfaces. Package names in the module can be
refactored independently of the names in the library, which can remain stable.
Though the editors in the libray will provide no functionality, for component
development all that is needed is that the class be present in the compile-time
class path.

To make this architecture as flexible as possible, it is also proposed to
introduce a new interface, PropertyEditorResolver, defined in its own library.
This interface defines a single method which, given a Java Beans
PropertyDescriptor, returns a property editor class which is appropriate for
editing the described property. VWP will provide one implemenation of this
resolver, which knows how to match interfaces in the VWP property editor library
with implementations in the VWP property editor module. It will also know how to
provide reasonable defaults for properties of JSF components. However, third
party component developers who wish to override the default resolutions can
provide a module with their own implementation of PropertyEditorResolver.

When Insync introspects a component for the first time, it will perform a lookup
to obtain all implementations of PropertyEditorResolver. For each component
property, it will ask each resolver, in order of priority, for an editor. If a
resolver returns an editor, the editor is used. If it returns null, the next
resolver is asked. If no resolver returns an editor, the global Java Beans
PropertyEditorManager will be queried for an appropriate editor.