[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] run-time configuration changes
|
Constraints are extra information about the setting that limit the potential
values for that setting. Could be min/max, could be a set of legal values, etc.
It's basically a "punt" to avoid over-specifying what can be represented by a
descriptor. Constraints are somewhat component-specific, though I can imagine
there are a significant set of common constraints that can be captured in a base
class.
I have not figured out how and when constraints are enforced. The idea is to
provide a management client some hints about how to construct a proper value for
a setting.
The setXXX and addXXX methods are intended for building up the
SettingDescriptor. I don't intend that you get a component's SettingDescriptor
and then start making changes to it. But someone's got to create the descriptor
in the first place. Is there a better way to specify this -- in some other
interface, for example?
...Greg
Michael McIntosh wrote:
Greg,
Can you provide more information about the "Constraints" in the
ISettingDescriptor?
Can you explain why there is code to dynamically change the
ISettingDescriptor? (seems like when a component changes what settings it
expects it justifies a restart)
Regards,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 07/07/2008 12:54:48 PM:
[image removed]
[higgins-dev] run-time configuration changes
Greg Byrd
to:
Higgins (Trust Framework) Project developer discussions
07/07/2008 12:57 PM
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
Please respond to "Higgins \(Trust Framework\) Project developer
discussions"
As discussed in our last phone meeting, a group at IBM has a need to
instantiate
configurable components, and to make their configurations persistent. I
promised that I would send some mail to the dev list to (hopefully)
kick off a
conversation.
This particular requirement raises at least two issues:
(1) Asking a configurable component about its configuration settings.
The
ISettingDescriptor interface was a first effort at this capability,
but it never
got further than that. Assuming that ISettingDescriptor is
descriptive enough,
there needs to be some mechanism to describe the settings and
constraints for a
particular component type.
That's what this discussion was about:
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg04721.html
(2) Once we create the setting for a component, how do we write the
settings to
the configuration file? This is complicated by the fact that there
are multiple
formats for configuration files, each with its own
ConfigurationHandler. When a
component is configured, all it sees is a Map that contains settings-- it
has
no idea what sort of file (if any) these settings came from.
One idea that came up during a discussion with the IBM folks was to
somehow
connect a component to the ConfigurationHandler that was responsible for
its
settings -- then we can pass off the responsibility for storing
those settings
to that handler.
-----
A third issue, which is not necessarily required for the current
scenario, is
how to change a configured components settings at run-time, and savethose
new
settings for later use.
Could call getSettings(), change map, and call configure() again with the
new
settings. Or could be a separate method for changing (e.g.,
setSettings()), so
that the component can distinguish a full configuration from an update.
Comments on any and all of these issues are welcomed.
...Greg
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
