To require consumers to register with the Portal's producer before interacting with it, you need to configure the Portal's behavior with respect to registration. Registration is optional, as registration properties. The producer can require registration without passing any registration properties in case of the default configuration. Let's configure our producer starting with a blank state:
eXo Platform will allow unregistered consumers to see the list of offered portlets, so the first checkbox ("Access to full service description requires consumers to be registered") is unchecked. You will, however, specify that consumers will need to be registered to be able to interact with our producer. Check the second checkbox ("Requires registration. Modifying this information will trigger invalidation of consumer registrations."). The screen should now refresh and display:
You can specify the fully-qualified name for your
RegistrationPolicy
and
RegistrationPropertyValidator
there. We will keep the default value. See
Section 5.7.2, “Registration configuration”
for more details. Let's add, however, a registration property called
email. Click "Add property" and enter the appropriate information in the fields,
providing a description for the registration property that can be used by consumers to figure out its
purpose:
Press "Save" to record your modifications.
Note
At this time, only String (xsd:string) properties are supported. If your application requires more complex properties, please let us know.
Note
If consumers are already registered with the producer, modifying the configuration of required registration information will trigger the invalidation of held registrations, requiring consumers to modify their registration before being able to access the producer again. We saw the consumer side of that process in Section 5.6.1, “Modifying a currently held registration”.
Customization of Registration handling behavior
Registration handling behavior can be customized by users to suit their Producer needs. This is
accomplished by providing an implementation of the
RegistrationPolicy
interface. This interface defines methods that are called by Portal's Registration service so that
decisions can be made appropriately. A default registration policy that provides basic
behavior is provided and should be enough for most user needs.
While the default registration policy provides the default behavior for most registration-related aspects,
there is still one aspect that requires configuration: whether a given value for a registration property
is acceptable by the WSRP producer. This is accomplished by plugging a
RegistrationPropertyValidator
in the default registration policy. This allows users to define their own validation mechanism.
Please refer to the
Javadoc™
for
org.jboss.portal.registration.RegistrationPolicy
and
org.jboss.portal.Registration.policies.RegistrationPropertyValidator
for more
details on what is expected of each method.
Defining a registration policy is required for the producer to be correctly configured. This is accomplished by specifying the qualified class name of the registration policy. Since we anticipate that most users will use the default registration policy, it is possible to provide the class name of your custom property validator instead of customizing the default registration policy behavior. Note that property validators are only used by the default policy.
Note
Since the policy or the validator are defined via their class name and dynamically loaded, it is important that you make sure that the identified class is available to the application server. One way to accomplish that is to deploy your policy implementation as the JAR file in your AS instance deploy directory. Note also that, since both policies and validators are dynamically instantiated, they must provide a default, no-argument constructor.