|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Because the Jini lookup service uses exact matching of the serialized forms of entry fields, it is critical that fields that will be used in template lookups have serialized forms that are consistent across all virtual machines. However, there is no guarantee that implementations of the Set interface, the declared type of the attributes field of UIDescriptor, have consistent serialized forms across all virtual machines. For example, java.util.HashSet, perhaps the most commonly used implementation of Set, does not guarantee a consistent serialized form. As a result, if a UIDescriptor that contains a HashSet in its attributes field is retrieved from a Jini lookup service, the serialized a form of the attributes field could be different if the UIDescriptor is reserialized as part of a template. This means that a UIDescriptor, when retrieved from a Jini lookup service and used immediately in a lookup template, may not match itself.
The Service UI API was defined under the assumption that
UIDescriptors in
Jini lookup templates might contain non-null
role and toolkit fields, but
would always contain null in their
attributes and factory fields.
It was expected that attributes could be inspected on the client side to
select between multiple matches of a Jini lookup. Once a
UIDescriptor was selected, it was expected that clients would use
the factory field to produce the selected UI. Because of
these assumptions, the UIDescriptor class was not designed to
ensure a template in which all four fields were non-null
would work. In other words, the designers were aware that the
attributes field could not be used in lookup templates,
but did not imagine that anyone would ever need to do that.
When used in templates intended for basic lookup of Jini services,
UIDescriptors will likely never have non-null
attributes fields. Nevertheless, UIDescriptors
used in templates intended to modify the attribute sets of
already-registered Jini services could very likely contain
non-null attributes fields. For example,
to add an object to the attributes set of a
UIDescriptor already registered as part
particular Jini service item, you must pass a template UIDescriptor
that exactly matches the registered UIDescriptor in
the attrSetTemplates parameter of either:
modifyAttributes method of net.jini.core.lookup.ServiceRegistration
modifyLookupAttributes method of net.jini.admin.ServiceRegistration
Unfortunately, the use case of modifying a UIDescriptor in
an already-registered Jini service item was never considered during the initial
design discussions leading to 1.0 release of the Service UI API. To
address this need, the 1.1 version of this specification narrows slightly
the contracts of these methods and constructors:
UIDescriptor(java.lang.String role,
java.lang.String toolkit, java.util.Set attributes,
java.rmi.MarshalledObject factory) constructor of
net.jini.lookup.entry.UIDescriptor
Locales(java.util.Set locales) constructor of
net.jini.lookup.ui.attribute.Locales
RequiredPackages(java.util.Map packages) constructor of
net.jini.lookup.ui.attribute.RequiredPackages
UIFactoryTypes(java.util.Set typeNames) constructor of
net.jini.lookup.ui.attribute.UIFactoryTypes
The 1.1 specification adds to the contracts of each of these constructors
a requirement that they copy the contents of the passed Set
or Map into a serializable read-only version that has a consistent serialized
form across all VMs. This new requirement yields the desired behavior when
attempting to modify UIDescriptors already part of service items registered in lookup
services.
|
Sponsored Links
|