[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] configuration component requirements
|
Greg (sorry for the name mix up. No
offense meant to you or Mike), Jim,
By "set", I mean to persist.
I agree that the application has control over the contents of the iConfiguration
object.
A "dynamic configuration change"
is the ability to change the ISettings in the IConfiguration and call the
component to change its configuration run time (if the components allow).
This change may not be persisted to the configuration store. An example
is to request a CP to increase its connection pool size or cache size,
based on system information.
Reading a configuration store with a
handler that builds the iConfiguration object can be agnostic of the configuration
data in the store. Portions of the application that need read the
configuration store and initialize a component would use one of the higgins
supplied handlers, or write their own.
Management of the Higgins configuration
(setting and persisting configuration data) requires an understanding of
the configuration data, and how to represent it to the UI (a schema and
metadata). IConfiguration could be used for management as well by
adding someway to get the configuration schema and passing a constructed
iConfiguration object to a persistance handler.
David
David Kuehr-McLaren
Tivoli Security
919.224.1960
"Jim Sermersheim"
<jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
05/17/2007 11:35 AM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx> |
|
|
To
| "Higgins (Trust Framework) Project
developer discussions" <higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [higgins-dev] configuration component
requirements |
|
So, there is a use case where a consuming application
needs to a) write config, and b) have it be persistent. It could
either implement IConfiguration itself and come up with its own set methods,
and mechanism for persistence, or we could implement set methods in one
or more common handlers (like in the xml file handler)
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 5/17/07
9:30 AM >>>
I'm not sure there should be set methods either. I think
we had a use-case for that once, but that use case may be irrelevant in
this model.
If an application is passing an IConfiguration, then it
implements the get* methods, and thus is in control of what gets "set".
The only utility I see is if an application was able to get an IConfiguration
somehow and needed to augment what was in there, _and_ the application
writer was too lazy to wrap that IConfiguration with his own, but would
rather call set* on it. But then, there are the dynamic/persistent issues
you brought up.
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 5/17/07 9:22 AM >>>
Don't blame Mike for that initial email -- it was mine.
I wasn't sure about setters on the configuration object. (This is
the kind of feedback I'm looking for.) But then we have the issue
of whether the dynamic setting is meant to be persistent (stored) or temporary.
I agree with the principle, however -- the configuration component should
insulate the other components from configuration data format issues.
I'm not sure I'm able to parse your last statement. Are you saying
that there should literally be separate components for these three activities?
Or that the proposed Configuration component should address all three
with distinct interfaces?
...Greg
David Kuehr-McLaren wrote:
Mike,
Commenting on this quote from bullet 2, "As it is now, IConfiguration
only has get methods" and all of bullet three.
I thought the goal of the configuration component was to separate the storage
of configuration data from the initialization of the components, such that
the components would not have a dependancy on a specific format for saving
the config data. From a tooling and exploiters perspective, applications
will need to edit and set configuration of components. The application
should have the option of the format to store the data, but Higgins could
provide base providers for the configuration store (properties file, etc.).
I see the runtime aspect of passing configuration to a component for initialization,
or dynamic configuration change a separate component from the ability to
read from a configuration store, and separate from the ability to set a
configuration store.
David
David Kuehr-McLaren
Tivoli Security
919.224.1960
The way I understand it, the object is a standard holder of configuration
settings. The other components can use it how and when they want
-- they'll need to have a configure method that takes in an IConfiguration
object. So I think this would work either way. If an already-initialized
component has its configure method called, it could say "No, I'm already
configured," or it could accept the new information and reconfigure
dynamically.
What we're standardizing is the way to pass such information in, so that
(a) it's programmatic, rather than file-based, and (b) each component does
not need to define its own data structure for doing this.
(Again, this is what I thought I heard -- others can correct me, if I'm
wrong.)
...Greg
Anthony Nadalin wrote:
So I have not looked at code but is this also for runtime
config or just initialization configuration ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Greg Byrd <gbyrd@xxxxxxxx>
I'm trying to nail down requirements for the Configuration component. I've
looked at Mike's configuration code for the STS, and I think I understand
it fairly well. I'm not quite sure what should be carried over into the
cross-cutting component, and what should be generalized.
What I'm thinking so far (and most of this comes verbatim from Mike's code):
(1) An ISetting interface that encapsulates a name, a type, and a value
(all strings) for a configuration setting.
(2) An IConfiguration interface, so that objects of this type can be passed
in to component-specific configuration methods. As it is now, IConfiguration
only has get methods -- to get a single ISetting, or the Map (where ISettings
are indexed by name), or an iterator over the Map.
(3) Should we then provide a set of implementations that convert data from
various forms to the map described above? For example, Mike's ConfigurationHandler
and the other various SettingHandler types allow an XML file/stream to
be parsed. Should this be in the Configuration component, or is it specific
to STS? Should we create other components, such as a property file reader,
or should this be done on an as-needed basis by different component owners?
...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
