[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] run-time configuration changes
|
Comments inline.
...Greg
Markus Sabadello wrote:
Hi,
Here are some thoughts:
1) Instead of introducing the new method setConfigurationHandler(),
wouldn't it be better to pass the IConfigurationHandler as an additional
parameter to the configure() method?
IMO, we should keep configure() simple. It may be that you want to just create
a simple map to configure a component, if you know what you're doing. No
configuration handler needed. Though I suppose you could pass null in that case.
Keeping them separate would allow changing the IConfigurationHandler
dynamically. Suppose you read configuration in from an XML file, but decide you
want to save the settings as an XRDS file (e.g., because you want to migrate
from one server to another). By setting the IConfigurationHandler before
applying updates, you control how the configuration data gets written. I'm not
sure how easy this is in practice, but theoretically the configuration data is
independent of its storage format.
2) Is there really a namespace "com.ibm.higgins.configuration.api", or
is that a mistake? :)
3) So the applyUpdates() method would basically write the whole
"mapGlobalSettings" back to a file, right? In theory I guess it would be
nice to be able to write only a part of the configuration back (i.e.
just the part that concerns your own IConfigurableComponent). E.g. have
a method
applyUpdates(...something-here-that-identifies-a-part-of-the-configuration...).
In cases where writing parts of the configuration is the same effort as
writing the whole thing (e.g. in the case of the XML
ConfigurationHandler), that method could simply call the "main"
applyUpdates().
Agreed. It would be nice to allow updating parts of a configuration. I'm not
sure how much of the global vs. component settings is truly general, as opposed
to driven by the initial STS configuration requirements. Who's to say that
there is a global map at all? And maybe its configuration spec is in a
different file from the component specs?
4) Shouldn't the ISetting.addChildSetting() method return the new
ISetting? Then you wouldn't have to search for it afterwards with a for
loop.
5) I like the idea that you don't HAVE to provide an ISettingDescriptor,
i.e. it can be built automatically when the configuration is read.
You would likely use the constraints and display string that would be useful for
a management UI, since these are not necessarily present in the configuration
file itself. But I think it's a good approach for the current requirements.
6) If you want to implement an ISettingDescriptor, how would you do
that? Would IConfigurableComponent have a method getSettingDescriptor() ?
Yes, every configurable component would have a getSettingDescriptor method.
7) I don't really understand the difference between Option 1 and Option 3.
8) I do like the ISettingDescriptor idea slightly better than the
ISetting idea, but both are great ways of solving the problem I think.
My concern about the ISetting solution is that it might require significant code
changes for components that already consume Maps for configuration.
BTW if you're interested, Dmitry made a configuration frontend for the
SAML2 IdP:
http://graceland.parityinc.net/saml2idp-server-config
But it's a very specific solution and probably not too useful as a basis
for a "general purpose" configuration frontend.
Markus
On Tue, Jul 15, 2008 at 8:39 PM, David Kuehr-McLaren
<dkuehrmc@xxxxxxxxxx <mailto:dkuehrmc@xxxxxxxxxx>> wrote:
I apologize if I sent this twice to the list. My email program says
I never sent it.
With much help from Greg Byrd and Rajalakshmi Iyer I have collected
the discussions on Configuration Management and created a proposal
page on the Wiki
http://wiki.eclipse.org/Higgins_Configuration_Management
It contains the general proposal and three options to consider. I am
leaning toward option 3, which is a hybrid of the first two options.
Please let us know you comments.
Thanks,
David
David Kuehr-McLaren
IBM Tivoli Security
919.224.1960
*David Kuehr-McLaren/Raleigh/IBM@IBMUS*
Sent by: higgins-dev-bounces@xxxxxxxxxxx
<mailto:higgins-dev-bounces@xxxxxxxxxxx>
07/07/2008 03:55 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
To
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
cc
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>,
higgins-dev-bounces@xxxxxxxxxxx <mailto:higgins-dev-bounces@xxxxxxxxxxx>
Subject
Re: [higgins-dev] run-time configuration changes
To put the need for the "constraints" in to context of a use case:
Application owner uses a UI (CLI and/or GIU) to configure an
instance of a context provider. With the UI, and application owner
can the context provider for the parameters it needs to configure an
instance of the provider. The UI will present a form to collect the
configuration data, and be able to persist the new configuration.
The UI will also be able to display existing configurations and
allow the user to update and delete CP configurations.
The UI application needs away to understand the model of the
configuration data needed by a context provider.
David
David Kuehr-McLaren
*Greg Byrd <gbyrd@xxxxxxxx <mailto:gbyrd@xxxxxxxx>>*
Sent by: higgins-dev-bounces@xxxxxxxxxxx
<mailto:higgins-dev-bounces@xxxxxxxxxxx>
07/07/2008 03:30 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
To
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
cc
higgins-dev-bounces@xxxxxxxxxxx
<mailto:higgins-dev-bounces@xxxxxxxxxxx>
Subject
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
<mailto: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
<mailto: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 <mailto:higgins-dev@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <mailto: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
